URL Encoder/Decoder: Percent-Encode Safely [2026]

URLs are constrained to a small set of ASCII characters. Anything else — spaces, accented letters, emoji, ampersands, plus signs, slashes inside a parameter value — must be percent-encoded so it survives transport through proxies, caches, and the URL parser at the destination server. Get the encoding wrong and your ?q=hello world becomes a mangled ?q=hello followed by an unparseable world token. Get the decoding wrong and a URL that contains a literal + shows up as a space.

Our URL encoder and decoder covers both directions, distinguishes between component encoding (for query values and path segments) and full-URL encoding (for entire links), and detects double-encoded strings so you can recover the original cleanly. This guide explains exactly which characters need encoding under RFC 3986, when to use encodeURIComponent vs encodeURI in JavaScript, and the gotchas that produce subtle bugs in production.

Reserved vs unreserved characters in RFC 3986

Component encoding vs full-URL encoding

The most common mistake is encoding the entire URL when you should be encoding just one part of it. encodeURI in JavaScript is for whole URLs and preserves reserved characters like ?, &, #, and / because they have structural meaning. encodeURIComponent is for individual query values, path segments, or form fields and does encode those reserved characters because at that level they are just data.

• Encode a query value: Use encodeURIComponent. ?q=hello world&safe=true becomes ?q=hello%20world&safe=true.
• Encode a path segment: Use encodeURIComponent. /users/Jane Doe becomes /users/Jane%20Doe.
• Encode an entire URL: Use encodeURI. The slashes and query separators stay intact; only spaces and unsafe characters get escaped.
• application/x-www-form-urlencoded: Spaces become + instead of %20; otherwise identical to component encoding. This is the form-submission default.

How to encode or decode a URL

1. Open the URL encoder/decoder
2. Paste your text or URL in the input
3. Pick Encode component, Encode full URL, or Decode
4. Output appears instantly; click Copy to clipboard
5. If decoding produced unexpected results, click Decode again to handle double-encoded strings

Double-encoding: the most common production bug

Double-encoding happens when a URL is encoded twice somewhere in its journey — typically because an HTTP client encodes a value the framework had already encoded. The visible symptom: %2520 in the final URL where you expected %20 (a space). The % from the original %20 got encoded a second time to %25, which when concatenated with 20 reads as %2520.

To fix: decode the string twice. Our tool detects the pattern automatically — if you paste a URL that decodes to another encoded URL, it offers a “decode again” button. The robust server-side fix is to encode at the boundary (where data leaves your code as a URL) and never in any layer above. Frameworks like Axios and Spring respect this by default; jQuery’s $.param and some legacy CMS pipelines do not.

Common gotchas

• Plus sign means space in form data, but not in URL paths. ?q=foo+bar decodes to foo bar in application/x-www-form-urlencoded; in a path segment, + stays as a literal plus. Our decoder respects the mode you pick.
• Encoding the protocol breaks the URL. Never encode https:// — the colon and slashes are structural. Use encodeURI on the whole URL or just encode the parts that need it.
• Tilde (~) is unreserved. Some old encoders escape it to %7E anyway. RFC 3986 says don’t. Our encoder leaves it alone.
• UTF-8 is the only sane choice. Encoding emoji or Chinese characters produces multi-byte sequences (%E4%B8%AD for “中”). Servers must decode as UTF-8 — Latin-1 / ISO-8859-1 fallbacks corrupt the data.
• Single quote (') is sub-delim. Encoded by encodeURIComponent to %27, but skipped by some legacy tools. Always include it in component encoding.
• Hash fragment is encoded with the same rules as the path, not the query. Spaces become %20, not +.

When NOT to use this tool

If your code already runs encodeURIComponent on a value, do not paste the result here and click “Encode” again — you will produce double-encoding bugs. Use this tool to decode a URL you got from a log file, to encode values copied from a spreadsheet before pasting into a URL by hand, or to verify what a server is actually receiving. For programmatic encoding inside a build pipeline, use the language-native function (encodeURIComponent in JS, urllib.parse.quote in Python, URLEncoder.encode(s, "UTF-8") in Java).

Frequently asked questions

What’s the difference between encodeURI and encodeURIComponent?

encodeURI assumes you have a full, structurally valid URL and only escapes characters that aren’t allowed anywhere in a URL. encodeURIComponent assumes the input is a single value (query parameter, path segment) and escapes all reserved characters. Use component for parts; use full only when you trust the input is already a valid URL skeleton with separators in the right place.

Why does my URL show %2520 instead of %20?

Double-encoding. A space was encoded to %20; then the whole string was encoded again, and the % became %25, producing %2520. Decode the URL twice to recover the original. The fix in code is to encode at exactly one layer of the request — never re-encode an already-encoded value.

Should I encode my URL parameters before sending an HTTP request?

If you build the URL with template literals or string concatenation, yes — wrap each parameter value in encodeURIComponent. If you use a library like fetch with the URL object and URLSearchParams, encoding is automatic. Don’t double up.

How do I encode emoji or non-Latin characters?

Use UTF-8 encoding (the default in JavaScript and Python 3). Emoji and Chinese characters are multi-byte sequences and produce strings like %F0%9F%8E%89 for 🎉 or %E4%B8%AD for “中”. Modern servers and CDNs handle this transparently; legacy IIS and some Java servlet stacks need explicit UTF-8 configuration.

Is my URL data uploaded?

No. The encoder/decoder runs in your browser via JavaScript. URLs and tokens you paste are never sent to our servers — useful for decoding tokens, signed URLs, or session strings without leaking them.

What’s the difference between URL encoding and Base64 encoding?

Different jobs. URL encoding makes a string safe to put inside a URL (only ASCII, only safe characters). Base64 makes binary data fit inside text-only formats like HTTP headers, email, or JSON. They are sometimes combined — a Base64-encoded JWT can still contain + and /, which need URL encoding (or use Base64URL, which substitutes - and _).

Related tools and guides

• URL Encoder/Decoder
• Base64 Encoder/Decoder
• HTML Encoder/Decoder
• JWT Decoder
• All coding tools