Free URL Encoder / Decoder
Encode or decode URLs and URI components instantly.
What URL Encoding Actually Does
URL encoding (also called percent-encoding) is the mechanism the web uses to fit arbitrary character data into a URL. URLs were originally designed for a tiny ASCII alphabet (letters, digits and a small set of punctuation) and characters outside that alphabet (spaces, accented letters, ampersands, slashes that aren't path separators, emoji, anything Cyrillic or CJK or Arabic) need to be escaped before they can travel safely through HTTP, server logs, browser address bars, copy-paste handlers and shell pipes. The encoding rule is straightforward: take the character's UTF-8 byte sequence, write each byte as a percent sign followed by two hexadecimal digits. A space (one byte, 0x20) becomes %20. An ampersand (0x26) becomes %26. The euro sign € (three UTF-8 bytes E2 82 AC) becomes %E2%82%AC. The encoded form is reversible (every URL parser on the web understands how to decode it) and the result is a string that contains only "safe" ASCII characters.
A Short History of the Encoding Rule
The percent-encoding convention dates back to RFC 1738 ("Uniform Resource Locators (URL)", Tim Berners-Lee, Larry Masinter and Mark McCahill, December 1994), the first formal URL specification published by the IETF. RFC 1738 defined the original "reserved" character set (characters with structural meaning in URLs that must be encoded when used as data) and the original "unreserved" set (characters that never needed encoding). The spec was substantially revised in RFC 2396 (Berners-Lee, Fielding, Masinter, August 1998) and again (definitively) in RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax", Berners-Lee, Fielding, Masinter, January 2005), which is still the formal URI specification today. RFC 3986 expanded the unreserved set to include the tilde character (~), formalised UTF-8 as the encoding for non-ASCII characters in IRIs, and tightened the rules around when reserved characters must be percent-encoded vs left as-is. For non-ASCII URIs, RFC 3987 ("Internationalized Resource Identifiers", Duerst and Suignard, January 2005) defined the IRI extension that lets URLs contain native Unicode characters, mapping IRI form to standard URI form via UTF-8 + percent-encoding. For domain names specifically, RFC 3492 defined Punycode (Costello, March 2003), the encoding used to represent Unicode domain labels (xn--exmpla-...) in DNS, which is structurally similar but uses a different algorithm. The modern web's de facto URL spec is the WHATWG URL Living Standard, edited by Anne van Kesteren, which encodes the actual behaviour of browsers, sometimes diverging from RFC 3986 for backward-compatibility with how URLs work in practice.
Reserved, Unreserved, and the Characters That Always Encode
RFC 3986 splits URI characters into three classes. Unreserved characters: letters A-Z a-z, digits 0-9, and the four marks - _ . ~: never need encoding and never gain meaning when they are encoded. Reserved characters: : / ? # [ ] @ ! $ & ' ( ) * + , ; =: have structural meaning in URLs (slash separates path segments, question mark introduces the query, ampersand separates query parameters, hash introduces the fragment). Reserved characters can appear unencoded in their structural role; they must be encoded when used as ordinary data. All other characters: control characters, spaces, percent itself, and any byte from a non-ASCII UTF-8 sequence, must always be percent-encoded. The percent character is special: it must be encoded as %25 when it appears as data, because an unencoded percent in URL context introduces a percent-encoded escape that the parser will try to decode. Skipping that step produces some of the most common URL-handling bugs in the wild.
encodeURI vs encodeURIComponent, When to Use Which
JavaScript ships two built-in encoders, both standardised in ECMAScript since 1999 (ES3). The choice between them is the single most common URL-encoding decision in web code, and getting it wrong produces subtle bugs that pass tests on simple input but break on real user data containing ampersands, hashes or slashes.
encodeURIComponent: encodes everything except the unreserved set. Use this when you are encoding a single piece of data that will be embedded into a URL, a query parameter value, a path segment, a fragment identifier, a form field value. The stringhello world&morebecomeshello%20world%26more: the ampersand inside is encoded, so it does not get parsed as a query-parameter separator when the URL is later read. This is the right tool for "I have user input, I want to put it in a URL safely."encodeURI: encodes only the characters that are illegal anywhere in a URL. It deliberately leaves the reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) intact because those characters might be doing structural work. Use this when you are encoding an entire URL that has been assembled with its structure already in place, a URL that contains its own?and&separators, a URL with non-ASCII characters in the path or query that need encoding without disturbing the URL grammar. The stringhttps://example.com/search?q=hello worldbecomeshttps://example.com/search?q=hello%20world: the slashes and question mark are preserved, only the space gets encoded.
The mental rule: encodeURIComponent for data, encodeURI for URLs. Use the wrong one and you'll either break URL structure (encodeURIComponent on a whole URL escapes the slashes and ampersands you needed) or fail to escape user input (encodeURI on a query value lets ampersands through and your data gets parsed as multiple parameters).
application/x-www-form-urlencoded, The Other Encoding
There is a second, related encoding used specifically for HTML form submissions: application/x-www-form-urlencoded. It looks almost identical to URL percent-encoding except for one detail, spaces are encoded as + rather than %20. This convention dates from the original HTML form spec and is preserved in the URL Living Standard for the application/x-www-form-urlencoded serialiser specifically. Decoders for form-encoded data must reverse the convention: a literal + in form data is encoded as %2B, and + in the encoded string decodes back to a space. JavaScript's URLSearchParams API handles this convention automatically; encodeURIComponent does not: it encodes spaces as %20 always. For query strings being assembled by hand for an HTML form action, use URLSearchParams rather than calling encodeURIComponent on each value individually.
When You Actually Need This Tool
- Debugging an API call. You're hitting a REST endpoint with a query parameter that contains spaces or special characters and getting back 400 errors or unexpected results. Encode the parameter value here, paste the result into your request, and confirm the API treats the input correctly.
- Building a shareable URL by hand. Constructing a deep-link to a search results page, a filtered view of a SaaS dashboard, or a pre-filled form, anywhere you need to embed a search query or selection state into the URL.
- Decoding a captured URL to read what's actually in it. A logged URL contains
%E2%9C%93%20done: what does that decode to? Paste, hit Decode, see✓ done. - OAuth and webhook URLs. The
redirect_uriparameter in OAuth flows must be precisely percent-encoded; getting it wrong produces opaque "redirect_uri mismatch" errors. Webhook URLs that contain query parameters with user data need careful encoding. - File names with non-ASCII characters in download links. A direct link to a file named
café-menu.pdfneeds theépercent-encoded for the link to work in all browsers and shell tools. - Database connection strings. PostgreSQL, MySQL and similar database URLs (
postgres://user:p@ssw0rd@host/db) need the password percent-encoded if it contains@,:,/or other reserved characters that would confuse the URL parser.
Security: Why Encoding Matters Beyond Aesthetics
Incorrect URL encoding is a long-standing source of web vulnerabilities. HTTP response splitting exploits unencoded line breaks (CR, LF, %0D%0A) in URL parameters that get reflected into HTTP headers, letting an attacker inject arbitrary headers or even a complete response. Open redirects exploit naive URL handling that doesn't properly decode and validate user-supplied URLs before redirecting. Server-side request forgery (SSRF) can abuse encoded characters to bypass URL allowlists, a regex that blocks "http://internal" misses "http://%69nternal" if the server decodes after the regex check. SQL injection via URL parameters isn't a URL-encoding issue per se but is exacerbated when single quotes and other SQL meta-characters survive into the database query. The OWASP recommendation since the early 2000s has been: encode at the boundary on the way in, decode at the boundary on the way out, never mix encoded and decoded forms in the same buffer. This tool does exactly the encode/decode step, what you do with the result is up to you, and the security responsibility is at the application layer.
Double Encoding, The Most Common Bug
Double encoding happens when an already-encoded string is encoded again. The space character in an already-encoded URL is %20; encode that again and you get %2520 (because % encodes to %25). When the receiver decodes once, they get %20 back instead of a space. When they decode twice (in the rare cases where double-decoding is supported), they get the space, but most parsers don't, and the URL silently contains visible %20 in the address bar. The fix is always: decode first if you don't know whether the input is already encoded, then encode exactly once. The same pattern applies in code, never call encodeURIComponent twice on the same string. If you must round-trip a value, decode the previous encoding before re-encoding for the new context. This tool's Swap button helps with the diagnostic cycle: paste a suspect URL, click Decode to see what's inside, click Swap, click Encode to get the canonical encoded form back.
Privacy: Browser-Only Execution
URLs frequently embed sensitive data, auth tokens in query parameters, user identifiers in path segments, search queries containing personal context, OAuth state values, webhook URLs that include API keys. Server-side URL encoders take a copy of every URL you paste into their logs. This tool uses JavaScript's built-in encodeURIComponent, encodeURI, decodeURIComponent and decodeURI functions running locally in your browser tab. No upload step, no telemetry, no logging, verify in DevTools' Network tab while you click Encode (no requests fire), or take the page offline (airplane mode) after it loads and the encoder still works. Safe for URLs containing tokens, API keys, internal endpoints, or any URL you wouldn't want copied onto a stranger's hard drive.
Frequently Asked Questions
When should I URL-encode text?
Whenever you embed user input or data containing special characters into a URL, search queries in a query string, file names in a path, parameter values in API requests, redirect targets in OAuth flows. Without encoding, special characters either break the URL structure (an unescaped & in a value gets parsed as a parameter separator) or introduce security vulnerabilities (an unescaped line break enables HTTP response splitting). The rule of thumb: any string that contains anything other than letters, digits, and the four marks -_.~ needs encoding before it goes into a URL.
What is double encoding and how do I avoid it?
Double encoding happens when already-encoded text gets encoded a second time, turning %20 into %2520 (because the percent character itself is encoded as %25). Receivers that decode once get back the half-decoded form rather than the original. Always: if you don't know whether a string is already encoded, decode it first, then encode it exactly once. In code, never call encodeURIComponent on the output of another encodeURIComponent.
Is this tool safe for sensitive URLs?
Yes. The encoder/decoder uses JavaScript's built-in functions running entirely in your browser. The URL you paste never crosses the network, verify in DevTools' Network tab while you click Encode (no requests fire), or take the page offline (airplane mode) after it loads. Safe for URLs containing OAuth tokens, API keys, internal endpoint addresses, or any value you wouldn't want logged on a third-party server.
Why does my form data have plus signs instead of %20?
HTML form submissions use a separate but related encoding called application/x-www-form-urlencoded, which encodes spaces as + rather than %20 as a historical convention. Both forms are valid in URL query strings; modern parsers accept either. JavaScript's URLSearchParams API uses the form-encoded convention; encodeURIComponent always uses %20. If your data needs to interoperate with old form-handling code, use URLSearchParams; if it's heading anywhere else, either form works.
What about non-ASCII characters and emoji?
Modern URL encoding uses UTF-8: each non-ASCII character is converted to its multi-byte UTF-8 representation, then each byte is percent-encoded. The euro sign (€, three UTF-8 bytes) becomes %E2%82%AC; an emoji like the rocket 🚀 (four bytes) becomes %F0%9F%9A%80. RFC 3987 (IRIs) and the WHATWG URL Standard both formalise this UTF-8-first convention. Older systems sometimes used Latin-1 or other encodings; if you're decoding ancient URLs and the result looks garbled, the source may have used a different character encoding before percent-encoding.