About URL Encoder / Decoder
URL encoding (also called percent-encoding) converts unsafe characters — spaces, non-ASCII letters, and reserved chars like & = ? — into %XX form, allowing URLs to safely carry any character. This tool offers bidirectional URL encode/decode, all processed locally in your browser. It supports both encodeURIComponent (full encoding for query parameters) and encodeURI (preserving path separators) semantics, and correctly handles UTF-8 multi-byte characters. Common scenarios include building query strings from user input, decoding Network tab URLs for debugging, encoding mailto: links, and handling double-encoding in OAuth callback URLs. Tip: Bookmark this tool for quick access whenever you need format conversion. All processing happens locally in your browser — no data upload, so feel free to paste sensitive content.
How to Use
- Open the URL Encoder / Decoder tool page
- Enter or paste your data into the input area
- View the real-time results and use the copy button to get the output
Use Cases
- Build query parameters — User input (non-ASCII, special chars) must be encoded before being appended to a URL, otherwise the backend will mis-parse it.
- Debug GET requests — URLs copied from browser DevTools Network tab are encoded — use this tool to read the original text.
- Handle special filenames — When uploading filenames with spaces or non-ASCII chars, HTTP paths require encoding for correct routing.
- OAuth callback URLs — The redirect_uri parameter is itself a URL — when nested as a query parameter it needs double-encoding.
- Mailto links — Pre-filled subject and body in mailto: links must be URL-encoded for special characters.
- Form data encoding — Encode application/x-www-form-urlencoded form payloads so that special characters in field values are transmitted correctly.
- Cookie value encoding — Percent-encode special characters in cookie values to comply with HTTP cookie specification requirements.
FAQ
How is URL encoding different from HTML entity encoding?
Entirely different. URL encoding uses %XX to represent bytes (space → %20). HTML entities use & + name (< → <). The former is for URLs, the latter for HTML body text.
Why is space sometimes + and sometimes %20?
application/x-www-form-urlencoded (form submission) uses + for space; URL paths and most modern contexts use %20. This tool defaults to %20.
Which characters need encoding?
RFC 3986 "unreserved" characters (A-Z, a-z, 0-9, - _ . ~) never need encoding. Others should be. ?#&= depend on position — encoded inside query values, raw as delimiters.
What happens if I encode twice?
You get %25XX (an encoded percent sign) — and a single decode only unwraps one layer. This is the most common backend bug; encode exactly once.
Can I put non-ASCII characters directly in a URL?
Modern address bars display them, but under the hood they're encoded as UTF-8 bytes + %XX. When constructing URLs in code, encode manually.
Any browser compatibility requirements?
This tool works in all modern browsers (Chrome, Firefox, Edge, Safari). No plugins or extensions required.
Can I use it offline?
After initial load, most features work offline. The core logic runs entirely in your browser with no network dependency.
Comments
💬 Comments are stored locally in your browser. Configure Giscus for cloud-based comments.