URL Encoder & Decoder

About this tool

URLs can only safely contain a limited set of characters — letters, digits, and a handful of punctuation marks like -, _, ., and ~. Everything else — spaces, ampersands, question marks, non-Latin characters, emoji — has to be represented using percent-encoding: each byte of the character is written as a percent sign followed by its two-digit hexadecimal value, so a space becomes %20 and an ampersand becomes %26. This isn't an arbitrary rule; it exists because certain characters are structurally meaningful inside a URL — ? starts the query string, & separates parameters, # marks a fragment — and if the actual data you're sending contains one of those characters unescaped, it gets misread as part of the URL's structure instead of as data.

This is most visible, and most commonly a source of bugs, in query string values. If a search term a user typed contains an ampersand — "salt & pepper," for instance — and you drop it into a query string unencoded, the URL parser will read everything after the & as a new parameter, silently truncating or corrupting the value you meant to send. Encoding the value first turns it into salt%20%26%20pepper, which survives being embedded in a URL intact and gets decoded back to the original string on the receiving end.

There's a subtlety worth knowing about: encodeURIComponent versus encodeURI (and their decode counterparts) handle different scopes. Encoding a single value that will become one query parameter — a search term, a redirect URL passed as a parameter, a filename — should use component-style encoding, which escapes everything except the small set of characters safe in any URL segment, including &, ?, and /. Encoding an entire URL you're about to display or store, where the structural characters like / and ? need to stay intact, uses the broader form. This tool performs component-style encoding, which is the correct choice for the overwhelming majority of day-to-day cases: encoding one value before inserting it into a URL you're building.

The UTF-8 handling matters as much as the escaping rules. A character outside the basic ASCII set — an emoji, an accented letter, non-Latin script — is first converted to its UTF-8 byte sequence, and each of those bytes is then percent-encoded individually, which is why a single character can expand into several percent-encoded triplets in the output. Getting this step wrong is a common source of mojibake (garbled text) when URLs cross between systems that assume different encodings. Everything here runs using your browser's built-in encodeURIComponent and decodeURIComponent, which implement this correctly by default — nothing is sent to a server.