URL Encoder and Decoder Online
Convert special characters into their URL-safe form and back. The one tool that Punycodes the domain instead of breaking it.
What is URL encoding?
URL encoding, also called percent encoding, replaces characters that cannot travel as-is in a web address with a percent sign followed by two hexadecimal digits. A space becomes %20 and ñ becomes %C3%B1.
It is needed because a URL only accepts a small set of characters: unaccented letters A–Z, digits and a handful of symbols. Everything else — spaces, accents, emoji, and also the symbols that carry structural meaning like ? or & — has to be encoded so it neither breaks the address nor changes its meaning.
The two digits after the % are the byte value in UTF-8. That is why one character can take several sequences: ñ is two bytes, written %C3%B1, and the euro sign is three, %E2%82%AC.
encodeURI, encodeURIComponent and the third option
Most developers know the first two and pick between them by trial and error. The rule is simpler than it looks, and there is a case neither of them covers.
| Mode | Use it for | Does it encode / ? &? |
|---|---|---|
| Component | A single parameter value | Yes |
| Full URL | An assembled address with an ASCII domain | No |
| Smart URL | A whole address, domain included | No, and the domain is handled separately |
An example of the first: to pass coffee & tea as a parameter value, you need component mode. Leave the & unencoded and the server reads it as the start of another parameter, truncating your value to «coffee».
A rule of thumb that survives most situations: if the string you are encoding is one value — a search term, a filename, a redirect target, a token — use component mode. If it is an address that already has its own structure, use one of the other two. The mistake that costs the most debugging time is reaching for component mode on a whole address and then wondering why the link no longer opens.
There is a case where nesting is exactly right, and it trips people up because it looks wrong: an OAuth redirect_uri. That parameter carries a complete URL as the value of another URL, so it genuinely has to be encoded with component mode, slashes and colons included. When you encode a URL for that purpose, seeing https%3A%2F%2F in the result is the sign that you did it correctly, not that something broke.
Why the domain is not percent-encoded
This is where nearly every tool gets it wrong, and the result is not cosmetic: they hand you an address that does not work.
DNS does not understand percent encoding. Domains with non-ASCII characters are encoded with Punycode, an entirely different algorithm that produces names with the xn-- prefix. The path and the query, by contrast, do use percent encoding. Two mechanisms for two parts of the same address.
The first address does not resolve: no name server knows what espa%C3%B1a.com is. The second does, and it is exactly what your browser produces internally when you type españa.com in the address bar — it shows you the pretty version and queries the xn-- one.
The Smart URL mode does that split and shows you the breakdown part by part. It also works in reverse: paste an address containing xn-- and you get it back readable. There is more on this on the letter ñ page, where we cover Punycode with more examples.
Accented characters in a URL
These are the real values for the characters that show up most in Spanish and Portuguese. The byte column explains why some cost more than others:
| Character | Encoded | Bytes |
|---|---|---|
| space | %20 | 1 |
| ñ | %C3%B1 | 2 |
| á | %C3%A1 | 2 |
| ü | %C3%BC | 2 |
| ç | %C3%A7 | 2 |
| ã | %C3%A3 | 2 |
| € | %E2%82%AC | 3 |
| & | %26 | 1 |
| / | %2F | 1 |
| ? | %3F | 1 |
| # | %23 | 1 |
| + | %2B | 1 |
| = | %3D | 1 |
| @ | %40 | 1 |
Computed with the same engine the tool uses.
A URL working with accents does not mean you should use them. Copied around it fills up with %C3%B1, it gets longer, and some older systems split it badly. For new addresses the usual practice is to fold the title into an unaccented slug: that is what the slug generator is for.
Which characters get encoded and which do not
The standard behind URL encoding is RFC 3986, and it sorts characters into three groups. Understanding the split prevents most of the surprises.
Unreserved: never encoded. Letters A–Z in both cases, digits 0–9 and four symbols: -, _, . and ~. Any tool that encodes those is doing extra work, and the result, while valid, ends up longer and less readable.
Reserved: encoded depending on where they sit. This covers : / ? # [ ] @ plus ! & ' ( ) * + , ; =. They carry structural meaning, so they must be encoded when they are part of a value and left alone when they act as separators. That is precisely the difference between component mode and full URL mode.
Everything else: always encoded. Spaces, accents, emoji and any character outside ASCII.
One detail almost no tool mentions, and worth knowing when you encode a URL from JavaScript: encodeURIComponent leaves five characters untouched that RFC 3986 does treat as reserved — !, *, ', ( and ). We checked by running it, not from memory. In practice it rarely bites, but some servers and API signature schemes treat them differently, and the resulting bug is hard to track down precisely because the address looks correct.
%20 or +: which one applies
Both stand for a space, but not in the same place, and mixing them up produces bugs that are hard to spot.
%20 always works. It is the encoding of a space anywhere in a URL: path, query or fragment.
+ only works inside form data submitted as application/x-www-form-urlencoded, which is what a classic HTML form does. Anywhere else a + is a literal plus sign, not a space.
The practical consequence: if someone searches for C++ and your system reads the pluses as spaces, you receive C followed by two spaces. That is why a literal plus is encoded as %2B whenever the distinction matters.
The checkbox lets you produce either form. If you are not sure which you need, leave it on %20.
Common mistakes
Encoding twice
Encode something already encoded and the % turns into %25, so %C3%B1 ends up as %25C3%25B1. The server decodes once and receives the literal text instead of the character. Spotting %25 in an address is almost always this.
Using component mode on a whole URL
It encodes :// and the slashes too, and the address stops being an address: it becomes a string that only works as a parameter value. That is correct when it is exactly what you want — a return URL nested inside another — but not for publishing the link.
Percent-encoding the domain
The mistake from the section above, and the quietest one: the address looks plausible and never resolves. Domains use Punycode.
Forgetting the hash
The # symbol starts the fragment, so everything after it never reaches the server. If it is part of a value, it has to travel as %23.
Frequently asked questions
Is it free? Do I need an account?
What is the difference between encodeURI and encodeURIComponent?
Why is the domain not percent-encoded?
How is ñ encoded in a URL?
Should I use %20 or + for spaces?
What is double encoding and why does it break things?
Related tools
Slug Generator
Turn a title into a clean URL with no accents.
The Letter Ñ
Ñ in domains, Punycode and double encoding.
Base64 Encode/Decode
Encode and decode Base64 with correct UTF-8.
Text to Binary
Convert text to binary and back, byte by byte.
SERP Simulator
Check whether Google will cut your title and URL.
Clean Text
Strip invisible characters and formatting at once.