Home/Other Calculators & Tools/URL Encoder / Decoder

URL Encoder & Decoder

Free · No sign-up · Runs entirely in your browser, nothing sent to a server

Percent-encode a value or a whole URL, or decode one back to readable text — with both encoding forms shown so you can take whichever you need.

Input
Output
Encoded
⏱️ Last reviewed: 26 July 2026 · Written and reviewed by Mohsin Iqbal under our editorial policy and calculation methodology.
📖 Approx. 12 min read🔒 Runs in your browser🔄 Updated 26 July 2026

On this page

  1. Why URLs Need Encoding At All
  2. The Distinction That Matters Most
  3. Reserved and Unreserved
  4. The Codes You Will Recognise
  5. Examples to Try
  6. The Plus Sign Problem
  7. Unicode and UTF-8
  8. Where It Goes Wrong in Practice
  9. In Code
  10. When to Use Which
  11. Security Notes
  12. Common Mistakes
  13. Frequently Asked Questions
  14. Pick the Right Function, Encode Once

🔑 Key Takeaways

Why URLs Need Encoding At All

A URL is a compact instruction, and several characters inside it have jobs. The ? starts the query string, & separates parameters, = joins a name to its value, / divides path segments and # marks a fragment.

So what happens when your data contains one of those characters? Without encoding, the browser cannot tell the difference between a separator and a literal character.

?search=fish & chips
  → the server sees a parameter "search" holding "fish " and another called " chips"

?search=fish%20%26%20chips
  → the server sees "search" holding "fish & chips" — correct

Percent-encoding removes the ambiguity. Each byte that could be misread is written as % plus its two-digit hexadecimal value, which no parser will mistake for a separator.

The Distinction That Matters Most

JavaScript provides two encoding functions, and they are not interchangeable. Nearly every URL-encoding problem traces back to using the wrong one.

encodeURIComponentencodeURI
Use it forA single value — one parameter, one path segmentA complete URL you want to make safe
Escapes : / ? & = #YesNo — they are structural
Escapes spacesYes, to %20Yes, to %20
Leaves aloneA–Z a–z 0–9 - _ . ! ~ * ' ( )The above plus all reserved characters
Watch what happens to a whole URL. Running https://example.com/my page?a=1 through encodeURIComponent produces https%3A%2F%2Fexample.com%2Fmy%20page%3Fa%3D1 — every structural character destroyed. That output is perfectly correct if you intended to pass the URL as a parameter value to another URL, and completely useless if you just wanted to fix the space. encodeURI gives https://example.com/my%20page?a=1, which is what you almost certainly wanted.

The tool above encodes as a component by default, because encoding a value is the more common need — and it shows the whole-URL result underneath whenever the two differ, so you can take whichever fits.

Reserved and Unreserved

RFC 3986 divides characters into groups. Unreserved characters are always safe and never need escaping; reserved characters carry meaning and must be escaped when used as data.

GroupCharactersBehaviour
UnreservedA–Z a–z 0–9 - . _ ~Never need encoding
Reserved — general: / ? # [ ] @Structural; escape when used as data
Reserved — sub-delimiters! $ & ' ( ) * + , ; =Meaningful within components
Everything elseSpace, quotes, < > % { } | \ ^ `, all non-ASCIIMust be encoded
The percent sign itself is the subtle one. Because % introduces an escape sequence, a literal percent must be written as %25. Miss that and "100% cotton" becomes malformed — the decoder tries to read %20 from "% c" and fails, or worse, silently produces something wrong. This is also why double-encoding is so common: encode once and %20 becomes %2520 on the second pass.

The Codes You Will Recognise

CharacterEncodedWhy it matters
space%20The one everybody has seen
!%21Sub-delimiter
#%23Otherwise starts the fragment
$%24Sub-delimiter
%%25Must be escaped or everything breaks
&%26Otherwise separates parameters
+%2BOtherwise may be read as a space
,%2CSub-delimiter
/%2FOtherwise divides path segments
:%3ASeparates scheme from the rest
=%3DOtherwise joins a name to a value
?%3FOtherwise starts the query string
@%40Common in email parameters

Examples to Try

Paste any of these into the encoder above. Every value was generated and verified rather than typed.

What it isRaw valueEncoded as a component
Search queryfish & chips near mefish%20%26%20chips%20near%20me
Email addressname+tag@example.comname%2Btag%40example.com
Product nameMen's 50% Cotton T-Shirt (L/XL)Men's%2050%25%20Cotton%20T-Shirt%20(L%2FXL)
City with spacesSunshine Coast, QLDSunshine%20Coast%2C%20QLD
JSON value{"filter":"price<100"}%7B%22filter%22%3A%22price%3C100%22%7D
Date range2026-07-01/2026-07-312026-07-01%2F2026-07-31
Path as a value/misc/internet/url-encode-decode.html%2Fmisc%2Finternet%2Furl-encode-decode.html
Text with emojiG'day 🇦🇺G'day%20%F0%9F%87%A6%F0%9F%87%BA

Assembling a real query string. Each value is encoded separately, then joined with the separators left intact:

https://api.example.com/search?q=fish%20%26%20chips&city=Sunshine%20Coast%2C%20QLD&limit=20
Notice what stayed unencoded. The ?, the & between parameters and the = joining each name to its value are all structure, so they remain literal. Only the values were encoded — which is exactly why you encode each piece before joining rather than encoding the finished URL. Encode the whole thing afterwards and you destroy the very separators you just added.
The product name is the instructive one. Men's 50% Cotton T-Shirt (L/XL) contains an apostrophe, a literal percent sign and a slash — three characters that each break a URL in a different way. The percent is the dangerous one: left alone, a decoder reads %20 out of "50% C" and either fails or silently returns something wrong.

The Plus Sign Problem

This one catches people repeatedly, because two different standards are in play.

ContextA space becomes
Percent-encoding (RFC 3986)%20
HTML form submission (application/x-www-form-urlencoded)+

Both are legitimate in their own context, but a standard decoder only understands the first. Run hello+world through decodeURIComponent and you get hello+world back, plus sign intact — because in a URL path a + is a literal plus, not a space.

You cannot resolve this automatically without knowing the source. If the string came from a submitted form, the + is a space. If it came from a URL path or was produced by encodeURIComponent, it is a genuine plus sign — and converting it would corrupt the data. That is why the tool above decodes normally and shows the form-data interpretation alongside it whenever a + is present, leaving the judgement to you.

Unicode and UTF-8

Percent-encoding works on bytes, not characters, so any non-ASCII text is converted to UTF-8 first. Each resulting byte then gets its own escape sequence.

CharacterUTF-8 bytesEncoded
a1a — unreserved, left alone
é2%C3%A9
3%E8%AA%9E
😀4%F0%9F%98%80

This is why an encoded URL containing non-English text looks so much longer than the original — a single Japanese character costs nine characters once encoded. Modern browsers display internationalised URLs in readable form while sending the encoded version, which is why the address bar and a copied link often look different.

Where It Goes Wrong in Practice

SymptomUsual cause
%2520 appearing in URLsDouble encoding — the string was encoded twice, so the % of %20 became %25
A parameter truncated at an ampersandThe value contained & and was not encoded as a component
Spaces arriving as plus signsForm-encoded data decoded with a percent-only decoder
An email address breaking a linkThe + in name+tag@example.com read as a space
Everything after # disappearingAn unescaped hash — the server never sees the fragment at all
A whole URL turned into gibberishencodeURIComponent applied to a complete URL
The fragment case is worth knowing. Everything after an unescaped # is handled entirely by the browser and never transmitted to the server. So a parameter value containing a hash does not merely arrive wrong — the rest of it never arrives at all, which makes it a genuinely confusing bug to diagnose from server logs.

In Code

LanguageEncode a valueDecode
JavaScriptencodeURIComponent(s)decodeURIComponent(s)
JavaScript (whole URL)encodeURI(s)decodeURI(s)
Pythonurllib.parse.quote(s, safe='')urllib.parse.unquote(s)
Python (form data)urllib.parse.quote_plus(s)urllib.parse.unquote_plus(s)
PHPrawurlencode($s)rawurldecode($s)
PHP (form data)urlencode($s)urldecode($s)
Note the two variants in Python and PHP. Python's quote produces %20 while quote_plus produces +; PHP's rawurlencode and urlencode split the same way. Choosing between them is the same decision as choosing between the two JavaScript functions — what matters is where the result is going. Python's quote also leaves / alone by default, which is why the safe='' argument is there.

When to Use Which

The question is rarely "should I encode?" — it is almost always yes. The real question is which of the two functions applies.

SituationEncodeWhy
REST API query parameterComponentThe value may contain & or =, which would otherwise be read as structure
Search termsComponentFree text can contain literally anything
Path segmentComponentA slash inside the value would create a fake directory level
OAuth redirect_uriComponentYou are putting a whole URL inside another URL — this is the classic case for component encoding
Redirect target in a linkComponentSame reason: a URL carried as a value
Fixing spaces in an existing URLWhole URLThe structure is already correct and must survive
A URL from user input, for displayWhole URLYou want it usable as a link, not flattened into a string
HTML form submissionHandled for youThe browser encodes it — but note it uses + for spaces
The OAuth case is worth singling out. A redirect_uri parameter carries a complete URL as the value of another URL — so it must be component-encoded, turning https://app.example.com/callback into https%3A%2F%2Fapp.example.com%2Fcallback. Getting this wrong is one of the most common OAuth integration failures, because the authorisation server sees a truncated or malformed redirect and rejects the request with an error that rarely says why.
Browser support. This tool uses encodeURIComponent, encodeURI and decodeURIComponent — standard JavaScript functions present in every browser for well over a decade, including Chrome, Firefox, Safari, Edge and their mobile versions. No plugin or permission is required, and since there is no server involved the page works offline once loaded. It will not run with JavaScript disabled.

Security Notes

Common Mistakes

  1. Using encodeURIComponent on a whole URL. It escapes the ://, slashes and question mark, producing something unusable as a link.
  2. Using encodeURI on a parameter value. It leaves & and = intact, so a value containing either breaks the query string.
  3. Double encoding. If you already see %2520, the string went through twice. Encode exactly once, at the point of assembly.
  4. Forgetting %25 for a literal percent. "50% off" needs encoding or the decoder reads the next two characters as hex and fails.
  5. Assuming + always means a space. It does in form data and does not in a URL path. You need to know where the string came from.
  6. Validating before decoding. Filters that check the raw string miss encoded payloads entirely. Decode once, then validate.
  7. Treating encoding as security. It is a transport convention, not a protection mechanism.

Frequently Asked Questions

What is URL encoding?

URL encoding, also called percent-encoding, replaces characters that are unsafe or have special meaning in a URL with a percent sign followed by two hexadecimal digits. A space becomes %20 and an ampersand becomes %26. It exists so that data inside a URL cannot be mistaken for the URL's own structure.

What does %20 mean?

It is an encoded space. The hexadecimal number 20 is 32 in decimal, which is the ASCII code for a space character. Spaces are not permitted in URLs, so every space in a web address is transmitted as %20 — or as a plus sign if the data came from an HTML form.

What is the difference between encodeURI and encodeURIComponent?

encodeURIComponent escapes everything that is not unreserved, including : / ? & = and #, which makes it correct for a single parameter value. encodeURI leaves those structural characters intact, which makes it correct for a complete URL. Using encodeURIComponent on a whole URL mangles it; using encodeURI on a value that contains an ampersand breaks the query string.

Why do spaces sometimes become plus signs?

Because HTML form submissions use a different convention. The application/x-www-form-urlencoded format sends spaces as +, while percent-encoding uses %20. Standard decoders only understand %20, so a plus sign survives decoding as a literal plus. Whether it should become a space depends entirely on where the string came from.

Which characters must be URL encoded?

Everything except the unreserved set — letters, digits, hyphen, full stop, underscore and tilde. Reserved characters such as : / ? # [ ] @ ! $ & ' ( ) * + , ; = must be encoded whenever they appear as data rather than as structure. Spaces, quotes and all non-ASCII characters always need encoding.

Why do I see %2520 in a URL?

That is double encoding. A space became %20 on the first pass, then the percent sign itself was encoded as %25 on the second, giving %2520. It means the value was encoded twice somewhere in your pipeline. Encode exactly once, at the point where you assemble the URL.

What is the difference between a URL and a URI?

A URI is any identifier for a resource; a URL is a URI that also says how to locate it, by including a scheme such as https. In everyday use the terms are interchangeable, and the encoding rules in RFC 3986 apply to both.

How are emoji and non-English characters encoded?

They are converted to UTF-8 bytes first, and each byte becomes its own escape sequence. An accented character such as é takes two bytes and encodes to %C3%A9; a Japanese character takes three and becomes something like %E8%AA%9E; an emoji takes four. This is why encoded URLs containing non-English text look so much longer than the original.

Is URL encoding secure?

No. It is fully reversible by anyone and provides no confidentiality at all — it is a transport convention, not a protection mechanism. It is also not sanitisation: encoded data still needs proper escaping before being inserted into HTML, SQL or a shell command. Never put tokens or passwords in a URL, since URLs appear in logs, browser history and referrer headers.

Why does my URL break at the hash symbol?

Because # marks the start of a fragment, which browsers handle locally and never send to the server. An unescaped hash inside a parameter value means everything after it is silently discarded before the request is even made. Encode it as %23 and the whole value arrives intact.

Do I need to encode an email address in a URL?

Usually yes, as a component. The @ becomes %40, and the + used in tagged addresses such as name+tag@example.com becomes %2B — otherwise it may be interpreted as a space and the address arrives wrong. Encoding the value properly avoids both problems.

Is this tool safe to use?

It runs entirely in your browser using the standard encodeURIComponent and decodeURIComponent functions. Nothing is transmitted, logged or stored — disconnect from the internet and it still works. That said, remember that encoding provides no protection: if the data is sensitive, encoding it changes nothing about who can read it.

Pick the Right Function, Encode Once

Almost every URL-encoding problem comes down to two decisions: whether you are encoding a value or a whole URL, and making sure it happens exactly once. Get those right and the rest follows.

The related tool worth knowing is the Base64 encoder and decoder, which solves the neighbouring problem of moving binary data through text-only channels. Both are encoding rather than encryption, and neither protects anything.

🌐 Internet & Tech Tools

URL Encoder / Decoder — percent-encoding for web addresses (this page) Base64 Encoder / Decoder — text to Base64 and back Password Generator — strong random passwords IP Subnet Calculator — CIDR, network and host ranges Bandwidth Calculator — transfer times and data usage

📋 References & Further Reading

RFC 3986 — Uniform Resource Identifier: Generic Syntax RFC 3987 — Internationalized Resource Identifiers MDN Web Docs — encodeURIComponent and encodeURI WHATWG URL Standard — how browsers actually parse URLs