Free URL encoder / decoder
Percent-encode any text so it survives a URL or query string, or decode an encoded URL back to readable text — RFC 3986 escaping, with the spaces, ampersands and non-ASCII characters handled for you, updated live, as you type.
On this page16 sections
Output is generated client-side in your browser. No data is transmitted to any server.
Results are estimates. Consult a professional.
What is URL encoding (and what this tool does)
URL encoding is the way arbitrary text is made safe to place inside a web address. A URL can only carry a limited set of characters, so anything outside that set — spaces, ampersands, accented letters, emoji — has to be rewritten as a code the browser and server both understand. This URL encoder / decoder does that translation both ways: it percent-encodes text so it survives a trip through a URL or query string, and it decodes an encoded URL back into the readable original.
The tool runs live as you type. Paste text into the encode box and each unsafe character becomes a %HH escape; paste an encoded string into the decode box and every %HH turns back into the character it stood for. A space, for example, becomes %20, and an ampersand becomes %26 so it can sit inside a value without being mistaken for a query separator.
How percent-encoding works (RFC 3986)
The rule comes from RFC 3986, the specification that defines URI syntax. Every character a URL is allowed to hold falls into one of three groups: unreserved characters, which are always safe; reserved characters, which have a structural job (separating the scheme, host, path, query and fragment); and everything else, which is unsafe and must be escaped. To escape a character, you take its byte value in UTF-8 and write it as a percent sign followed by that byte in two hexadecimal digits — the "%HH" form.
Encoding vs decoding: which side you need
The two directions answer opposite questions. Encode when you are building a URL — you have raw text (a search term, a name, a JSON value) and you need to drop it into a path segment or query parameter without breaking the address. Decode when you are reading one — you have a URL full of %HH escapes (from a browser bar, a log, or a redirect) and you want the human-readable text back.
- Encode — text → URL-safe string. Use it before putting user input into a link, an API request, or a redirect target.
- Decode — URL-safe string → text. Use it to inspect what a captured or logged URL actually contains.
- Round-trip — decoding an encoded string returns the original exactly, and encoding then decoding is lossless. The tool lets you verify this in place.
A worked example: encoding a query value
Say you want to pass the literal text hello world&x=1 as a single search value in a URL like ?q=…. Left as-is, the space breaks the URL and the & and = would be misread as query structure. Here is what the encoder does, character by character.
Step 1 — Keep the unreserved characters
The letters in "hello" and "world", the "x", and the "1" are all unreserved (A–Z, a–z, 0–9), so they pass through untouched.
Step 2 — Escape the space
A space is unsafe in a URL. Its byte value is 0x20, so it becomes %20.
Step 3 — Escape the reserved & and =
The ampersand and equals sign are reserved query delimiters. To use them as literal text inside a value they must be escaped: & → %26 and = → %3D.
Step 4 — Read off the result
Putting it together, hello world&x=1 encodes to hello%20world%26x%3D1 — exactly what the encode box shows and what JavaScript's encodeURIComponent() returns. Decode that string and you get the original back, character for character.
encodeURIComponent vs encodeURI
JavaScript ships two encoders, and using the wrong one is the most common URL-encoding mistake. They differ only in how they treat the reserved characters that give a URL its structure.
- encodeURIComponent() — encodes a single piece of a URL (one query value, one path segment). It escapes the reserved characters too, including
/ ? # & = +, because inside a value those characters are just data. - encodeURI() — encodes a whole, already-assembled URL. It leaves the reserved delimiters alone so the URL keeps working, and only escapes spaces and other clearly unsafe characters.
The practical rule: use encodeURIComponent for the parts you are inserting, and reserve encodeURI for a complete URL you only need to tidy up. Encoding a full URL with encodeURIComponent would turn its :, / and ? into %3A, %2F and %3F and break it.
Spaces: %20 versus + in query strings
Spaces have two valid encodings, and which one is correct depends on where the space sits. In a normal URL — a path or a query built per RFC 3986 — a space is always %20. But in form data submitted as application/x-www-form-urlencoded (the default for HTML form POSTs and many query strings), a space is encoded as a plus sign, +.
| Context | A space becomes | A literal "+" becomes |
|---|---|---|
| URL path or RFC 3986 query | %20 | + (already safe, often left as-is) |
| Form-encoded body / query (x-www-form-urlencoded) | + | %2B |
The "+" means space convention comes from the HTML form-urlencoded serialization, not RFC 3986. Per the WHATWG URL Standard, application/x-www-form-urlencoded encodes space as "+" and a literal plus as %2B.
%20 is the safe default: it is understood everywhere, and most servers also accept + as a space in the query. The trap is the literal plus sign. If your text really contains a "+", it must be encoded as %2B — otherwise the receiving side may decode it as a space and silently corrupt your value.
When you need URL encoding
URL encoding shows up anywhere text that you do not control gets placed into a web address. It is rarely something you do by hand once and forget — it runs on most requests a web app makes.
- Query parameters — search terms, filters and user input dropped into
?key=valuepairs, so an "&" inside a value never splits the parameter. - API calls — building request URLs from variables, especially anything containing spaces, slashes, or non-ASCII text.
- Redirects — passing a destination URL as a parameter (a
?next=or?redirect_uri=), where the inner URL must be encoded so its own?and&do not leak into the outer one. - Path segments — file names, slugs, or IDs that may contain reserved characters or spaces.
- Internationalized text — names, cities, and search terms in any language, whose UTF-8 bytes are percent-encoded so the URL stays ASCII-safe.
Reserved vs unreserved characters
Knowing which characters are safe explains exactly what the encoder will and will not touch. RFC 3986 splits the printable ASCII characters into the unreserved set (always left alone) and the reserved set (escaped when used as data inside a component).
| Group | Characters | Encoded? |
|---|---|---|
| Unreserved | A–Z a–z 0–9 - _ . ~ | Never — always safe |
| Reserved (gen-delims) | : / ? # [ ] @ | Escaped when used as a literal value |
| Reserved (sub-delims) | ! $ & ' ( ) * + , ; = | Escaped when used as a literal value |
| Everything else | space, non-ASCII, control chars | Always — encoded as %HH per UTF-8 byte |
Reserved and unreserved sets per RFC 3986 §2.2–2.3. Reserved characters are only encoded when they appear as data; as delimiters (the "/" between path segments, the "&" between query pairs) they stay literal.
The double-encoding pitfall
The classic bug is encoding something that is already encoded. Percent-encoding is not idempotent: a "%" is itself a reserved character, so encoding an already-encoded string escapes its percent signs. Run %20 through the encoder a second time and the "%" becomes %25, giving %2520 — which decodes back to the literal text "%20", not a space.
The fix is to encode each value exactly once, at the moment it enters the URL, and to decode exactly once when you read it. Trouble usually comes from a value that was already encoded upstream (for instance, a redirect target you received) being encoded again before you send it on. When in doubt, decode first to confirm you are starting from raw text, then encode a single time.
Does this URL encoder run in my browser?
Yes. The encoding and decoding happen entirely in your browser with built-in JavaScript. The text you paste is never stored, logged, or sent to any server — there is no network request, so the tool works the same offline. That makes it safe to decode URLs that contain tokens or identifiers without them leaving your machine.
Need a different format? Our Base64 encoder / decoder handles binary-safe text and data URIs, and the HTML entity encoder escapes the <, > and & characters for safe display inside HTML rather than inside a URL.
URL encoding definitions
How accurate is this URL encoder?
The output is exact. The tool uses the browser's own standards-compliant encoder, so it matches RFC 3986 percent-encoding and JavaScript's encodeURIComponent byte for byte — "hello world&x=1" always becomes "hello%20world%26x%3D1", and decoding is a perfect inverse. There is no approximation involved.
The one judgement the tool cannot make for you is context: whether your space should be %20 or + depends on whether you are building a normal URL or form-encoded data, and whether a reserved character is a delimiter or data depends on your intent. Use the encode side for values you are inserting and the decode side to read captured URLs. For related formats, see the Base64 encoder and the HTML entity encoder.
Frequently asked questions about the free URL encoder / decoder
About this URL encoder / decoder
This URL encoder / decoder runs entirely in your browser. The text you paste is never stored, logged, or sent to any server — the percent-encoding is computed locally with the browser's own standards-compliant encoder, so it works the same offline and matches RFC 3986 and encodeURIComponent byte for byte. It only changes the form of text to make it URL-safe; it is not encryption and hides nothing.
Looking for more developer utilities? Try the Base64 encoder or the HTML entity encoder, or browse the rest of our dev tools.