URL Encode — Encode Special Characters for URLs in Your Browser
URL-encode special characters, spaces, and non-ASCII text for safe URL usage. RFC 3986 compliant, runs entirely in your browser. No uploads, no limits.
Percent-encoding is the oldest encoding standard still in daily use. It was specified in RFC 1738 in 1994 and refined in RFC 3986 in 2005, and the rules have not changed since: characters that are not allowed in a URL — spaces, non-ASCII text, delimiters, and characters reserved for URL structure — are replaced with % followed by two hexadecimal digits. The encoding is so fundamental to the web that every browser, every HTTP library, and every web framework does it automatically, and the only time anyone thinks about it is when the automation fails. The automation fails when a tool encodes too little (a space passed to fetch as a literal space), too much (a / path separator encoded in a path), or in the wrong character set (a Latin-1-encoded query value sent to a UTF-8 endpoint).
The choice between encoding modes — encode everything, encode query strings only, encode path components — is the choice that determines whether the output works or breaks. Query-string mode encodes &, =, and ? because those are the delimiters that separate key-value pairs. Path-component mode encodes / and : because those are the delimiters that separate path segments and scheme declarations. The default ‘encode all special characters’ is the safest: it produces a string that can survive anywhere in a URL. The per-component modes exist because URLs are made of components, and each component has its own safe-character set.
For a final hand-off: if the encoded string is a query parameter value, pair the encoding with the Query String Parser tool to assemble the full URL. If the encoded string is part of an HTML document, use the HTML Entity Encode tool for entities inside tag attributes — URL encoding in HTML is only valid inside href and src attributes, not for general content. If you are building a URL from parts, use the URL Parser tool to validate the assembled result before shipping it to production.
How to use
Type or paste the text
Drop the string into the input area. Spaces become `%20`, special characters become percent-hex triples, and non-ASCII text is encoded as UTF-8 byte sequences. The output updates in real-time.
Choose the encoding set
Default is 'encode all special characters' for the safest transport. Switch to 'encode query-string only' for parameter values (encodes `&`, `=`, `?` but leaves `/` and `:` alone). Component-only mode is useful for single path segments.
Copy the encoded URL
Copy the encoded string to your clipboard. The output is safe to paste directly into a URL bar, an `<a href>` attribute, or a `fetch()` call without further escaping.
Frequently asked
What is percent-encoding and how does it work?
Percent-encoding (also called URL encoding) replaces unsafe characters with `%` followed by two hexadecimal digits. A space becomes `%20`, an ampersand `%26`, and a Euro sign `%E2%82%AC` (the three UTF-8 bytes). The encoding is specified in RFC 3986 and is the only way to embed arbitrary bytes in a URL.
Does URL encoding mean the text is encrypted or hidden?
No. URL encoding is a transport encoding, not encryption. Anyone who sees `%48%65%6C%6C%6F` can decode it to 'Hello' with any decoder. The purpose is to make the string safe for transit through URL parsers, not to conceal it.
Why are some characters not encoded by default?
Characters in the 'unreserved' set (A-Z, a-z, 0-9, `-`, `.`, `_`, `~`) are URL-safe in all positions and never need encoding. Characters like `/`, `?`, and `#` have structural meaning in URLs and are only encoded when you want them treated as literal characters, not as path separators or query delimiters.
How does the tool handle non-ASCII text like Chinese or emoji?
Each non-ASCII character is converted to its UTF-8 byte sequence, and each byte is percent-encoded separately. The character 字 (U+5B57, three UTF-8 bytes E5 AD 97) becomes `%E5%AD%97`. This works for any Unicode character and is what RFC 3986 requires.
Limitations
- No double-encoding detectionThe tool encodes whatever text you give it. If the input is already partially encoded (contains `%20`), the `%` will itself be encoded to `%25`, producing double-encoded output. Decode first with the URL Decode tool if you suspect the input is already encoded.
- Path-vs-query ambiguityThe tool does not parse the input as a URL. It treats the entire input as a single string to encode. If you need to encode only some parts of a URL, use the URL Parser tool to split the URL into components first.
- No punycode or IDN handlingInternationalised domain names (IDN) like `münchen.de` must be converted to Punycode (`xn--mnchen-3ya.de`) before DNS resolution, but percent-encoding and Punycode are separate standards. The tool only handles the path, query, and fragment portions.
Platform notes
- macOS
- Terminal equivalent: `python3 -c 'import urllib.parse; print(urllib.parse.quote("text"))'`. The browser tool is the right pick for ad-hoc encoding from a clipboard or chat without opening a terminal.
- Linux
- CLI equivalent: `echo -n 'text' | python3 -c 'import urllib.parse,sys; print(urllib.parse.quote(sys.stdin.read()))'`. The browser tool avoids the quoting chore for strings with single quotes or special characters.
- Windows
- PowerShell equivalent: `[System.Web.HttpUtility]::UrlEncode('text')`. The browser tool works offline in restricted environments where PowerShell access is limited.
- Web
- Runs entirely client-side. Works offline once the page has loaded. Useful for quick encoding of query parameters during development or debugging.