Kodowanie / Dekodowanie URL

What the URL encoder and decoder is for

The moment you place arbitrary text into a web address, some of that text turns dangerous: a space, an ampersand, a question mark, a slash, or a non-Latin character can change what the URL means or break it outright. This tool percent-encodes text so it is safe to drop into a link, a query string, a redirect parameter, or an API call, and it decodes percent-encoded strings back into human-readable text. You reach for it when you are hand-building a URL, debugging why a query parameter arrives mangled on the server, reading an OAuth redirect, or copying a value out of an address bar that is full of %20 and %2F sequences and you just want to know what it says.

How percent-encoding works

Percent-encoding replaces an unsafe character with a percent sign followed by the two hexadecimal digits of that character's byte value. A space becomes %20, a slash becomes %2F, and an ampersand becomes %26. For anything outside ASCII, the text is first encoded as UTF-8 and then each resulting byte is escaped, which is why a single accented letter or emoji can expand into several %XX pairs. Only a small set of "unreserved" characters is ever left untouched: the letters, the digits, and the four marks hyphen, underscore, period, and tilde. Everything else is a candidate for escaping, and how aggressively it is escaped depends on which of the two encoders you choose.

This tool exposes both encoders the web platform actually ships, and picking the right one is the whole game:

• Component mode mirrors encodeURIComponent and escapes aggressively, including the structural characters &, =, ?, /, and #. Use it for a single piece of data that lives inside a URL, such as one query-parameter value or one path segment.
• Whole-URL mode mirrors encodeURI and deliberately leaves the structural characters like :, /, ?, &, and # alone. Use it when you already hold a complete, valid URL and only want to fix stray spaces or non-ASCII characters without destroying its structure.

Concrete examples and use cases

Say a visitor searches for fish & chips. In component mode that becomes fish%20%26%20chips, which you can safely place after ?q= because the ampersand is now escaped and can no longer be mistaken for a parameter separator. Encode the whole address https://example.com/a b in whole-URL mode and only the space is fixed, giving https://example.com/a%20b while the :// and the slashes survive intact. Decoding runs the same logic in reverse, so pasting a captured redirect such as next=%2Fdashboard%3Ftab%3Dbilling reveals the readable /dashboard?tab=billing hiding underneath it.

Tips and gotchas

The classic bug is choosing the wrong mode. Encode an entire URL with component mode and you escape the :// and every slash, producing a string that is valid text but no longer a working link. Encode a single value with whole-URL mode and an embedded & or = stays literal and silently corrupts the surrounding query string. A second trap is the plus sign: percent-encoding does not turn spaces into + — that convention belongs to HTML form submissions using application/x-www-form-urlencoded, so a + you decode may have meant a literal plus or a space depending on where it came from. Finally, never double-encode: running an already-encoded string through the encoder again turns every % into %25 and produces gibberish.

Everything stays on your device

All of this happens locally in your browser — the text and URLs you paste never leave your device, are never uploaded, and are never logged. Because URLs so routinely carry session tokens, email addresses, and other identifying parameters, keeping the operation on your own machine is a real privacy win rather than a slogan, and it means the tool keeps working with your connection off. If you more often need to pull a URL apart than to build one, our query string parser breaks a full address into its individual decoded key/value pairs, and it runs entirely in the browser too.