URL Encoding and Decoding, Explained for Developers
Type a space into a URL, or a Cyrillic word, or an ampersand that belongs to your data rather than to the address itself, and something has to give. The web only guarantees safe transport for a small, predictable set of ASCII characters. Everything else has to be wrapped in a format that routers, servers and browsers all agree on. That format is percent-encoding, more commonly called URL encoding, and this page lets you convert text in either direction directly in your browser.
What percent-encoding actually is
The rule is mechanical and easy to follow. Any character that cannot appear literally is replaced by a % sign followed by two hexadecimal digits that spell out the byte value of that character. A space becomes %20. A plus sign becomes %2B. The number sign becomes %23. When a character maps to several bytes, as most non-ASCII text does under UTF-8, you simply get several triplets in a row: the euro sign turns into %E2%82%AC. Decoding reverses the process, reading each triplet back into its original byte.
This convention is defined in the URI specification (RFC 3986) and it is deliberately boring. Boring is the point. Every well-behaved HTTP client and server on the planet implements the same rules, so a link that is correctly encoded in one place arrives intact everywhere else.
Why it has to exist
URLs carry two kinds of characters with very different jobs. Reserved characters such as /, ?, #, &, = and : are structural. They tell a parser where the path ends and the query string begins, or where one parameter stops and the next starts. If your actual data contains one of those symbols, it must be encoded so the parser does not mistake it for punctuation. An order reference like A&B/2024 dropped raw into a query string would be misread as two parameters and a path segment.
Then there are unsafe and non-ASCII characters: spaces, quotation marks, angle brackets, accented letters, emoji, anything outside the plain ASCII range. These have no business appearing literally in a URL, either because they get mangled in transit or because they have no defined representation. Encoding them keeps links clean and predictable instead of leaving the outcome to chance.
Where it shows up in real work
Query strings are the classic case. Every value you append to ?key=... should be encoded so user input cannot break the structure. The same applies to HTML form submissions sent as application/x-www-form-urlencoded, where the browser encodes field values automatically (and, by historical convention, turns spaces into + rather than %20). You will also meet it when building links that point at pages with non-Latin titles, when constructing API requests by hand, when passing redirect targets as parameters, and when debugging why a request that looks fine in the address bar arrives garbled at the server.
encodeURI versus encodeURIComponent
JavaScript ships two encoders, and choosing the wrong one is a common bug. The difference is about scope. encodeURIComponent is for a single piece of data, such as one query value. It encodes nearly everything, including the reserved characters /, ?, :, @, &, =, + and #. That is exactly what you want when the data is allowed to contain those symbols as ordinary text.
encodeURI is for an entire address you intend to keep working. It leaves the structural characters alone, so the slashes, colons and question marks that hold the URL together survive. Use it when you have a full URL and only want to clean up spaces or non-ASCII characters; reach for encodeURIComponent whenever you are inserting a value into a larger URL. A simple rule of thumb: encode the whole link with encodeURI, encode the parts you stuff in with encodeURIComponent.
Everything stays on your machine
This tool runs entirely in your browser. Text you paste is encoded or decoded locally with the same standard routines and never travels to a server, which makes it safe for tokens, signed parameters or anything else you would rather not send across the wire. If you work with other text transformations, the Base64 converter sits right alongside it, and you can browse the full set of developer tools for more day-to-day helpers.
Frequently asked questions
What does %20 mean in a URL?
It is an encoded space. The space character is not allowed literally in a URL, so it is replaced by a percent sign and the hexadecimal value 20, which is the byte value of a space.
Why do I sometimes see a plus sign instead of %20?
HTML form data of type application/x-www-form-urlencoded encodes spaces as a plus sign by historical convention. In a normal path or query, a space is encoded as %20. Both decode back to a space in their proper context.
When should I use encodeURIComponent instead of encodeURI?
Use encodeURIComponent for a single value you are inserting into a URL, such as a query parameter, because it encodes reserved characters too. Use encodeURI for a complete address when you want to preserve the slashes, colons and question marks that hold it together.
Does URL encoding change the meaning of my data?
No. Encoding is fully reversible. Decoding the result gives back exactly the original text, byte for byte, as long as the same character set is used on both ends.
How are non-ASCII characters like accents or emoji handled?
They are first turned into UTF-8 bytes, then each byte becomes its own percent triplet. A single accented letter or emoji can therefore expand into several triplets in the encoded output.
Is my text sent to a server when I use this tool?
No. Encoding and decoding happen entirely in your browser. Nothing you paste is uploaded, so it is safe to use with private or sensitive strings.