🔗 URL Encoder / Decoder
Encode or decode URLs and text instantly — spaces, symbols, and special characters handled correctly.
What Is URL Encoding, Exactly?
A URL can only officially contain a very narrow set of characters safely: letters A-Z, digits 0-9, and a handful of symbols like - _ . ~. Everything else — spaces, ampersands used outside their normal role, emojis, Urdu/Arabic/Hindi text, even a plain apostrophe in some contexts — has to be converted into a "percent-encoded" byte sequence, written as % followed by two hex digits representing that character's byte value. This isn't an arbitrary rule; it's defined in the official URL specification (RFC 3986) so that every browser, server, and app on the internet interprets a URL's structure identically. Without it, a URL like ?q=50% off would be genuinely ambiguous to a computer — is that a literal percent sign, the start of an encoded character, or a typo?
A Real Before/After Example
Take this raw search phrase someone types into a search box: iPhone 15 Pro & 5% discount
Encoded as a URL component, it becomes: iPhone%2015%20Pro%20%26%205%25%20discount
Notice exactly what happened: every space became %20, the & became %26 (because an unescaped & would be read as separating two different query parameters), and the literal % in "5%" became %25 (because % is the escape character itself, so a literal percent sign has to be escaped too). This is the exact transformation this tool performs instantly, live as you type.
How to Use This Tool
- Paste your text or URL into the input box.
- Choose Encode or Decode depending on what you need.
- Choose Component or Full URI mode (see the detailed difference below) — results update instantly as you type, no button click needed.
- Copy the result, or click Swap to immediately reverse the operation using the output as your new input — useful for double-checking a round trip.
Component Encoding vs. Full URI Encoding — The Difference That Actually Matters
This is the single most common point of real confusion, and picking the wrong one is one of the most frequent causes of silently broken links, especially for developers passing data into query strings.
Component encoding (encodeURIComponent) escapes everything except unreserved characters (letters, digits, - _ . ! ~ * ' ( )). Critically, it also escapes & = ? / : # @ — the characters that give a URL its structure. Use this when encoding one single piece of data that's going to be inserted into a URL, such as one query parameter's value, precisely because that value might contain those structural characters and you don't want them accidentally changing the URL's meaning.
Full URI encoding (encodeURI) leaves ; , / ? : @ & = + $ # untouched, on the assumption you're encoding an entire, already-structured URL and don't want to break its existing query string or path separators. Use this only when encoding a whole URL as one unit — for example, adding a space or an accented character directly into an existing link without disturbing its query string.
Concrete example of what goes wrong if you mix these up: Say a user's search input is cats & dogs, and you're building https://example.com/search?q=cats & dogs. If you "encode" this entire string with Full URI mode, the & stays as a literal & — which a server will now misread as: parameter q = "cats ", and a brand new parameter named dogs with no value. The search silently breaks. Encoding just the value cats & dogs with Component mode correctly produces cats%20%26%20dogs, keeping it as one single, correct parameter value.
URL Encoding vs. Base64 Encoding — Not the Same Thing
These two are frequently confused because both turn text into a scrambled-looking string, but they solve different problems. URL encoding (percent-encoding) exists specifically to make text safe to embed inside a URL while keeping it mostly still readable — spaces become %20, letters stay as letters. Base64 encoding is a completely different scheme that converts any binary data (including images or files) into a compact text representation using a 64-character alphabet, and it's unreadable at a glance, with no relationship to URL structure at all. If you need to safely pass binary data or an entire file inside a URL, you typically Base64-encode it first, then URL-encode the Base64 result, since Base64 itself can contain characters like +, /, and = that also need URL escaping.
Where Encoding Applies Differently Within a URL
| URL Part | Example | Encoding Behavior |
|---|---|---|
| Path segment | /products/red shoes | Spaces and special characters need encoding; / stays as the path separator |
| Query parameter value | ?q=red shoes | Encode the value only, using Component mode, so &/= inside it don't break other parameters |
| Fragment (after #) | #section-2 | Rarely needs encoding unless it contains spaces or special characters |
| Domain name | example.com | Never percent-encoded this way; non-English domains use a separate system called Punycode |
Real-World Scenario Walkthroughs
Scenario 1 — Sharing a Google Maps search link with Urdu text: If you paste an address in Urdu into a maps link, your browser automatically percent-encodes each character into its UTF-8 byte sequence — this is why maps links you copy often look like a long string of %D8%A7%D9%84... characters. Decoding that string with this tool instantly reveals the original readable text, which is useful for verifying a link actually points where you expect before sharing it.
Scenario 2 — Building an API request manually: Many weather, currency, or translation APIs take a city name or text string as a query parameter, e.g. ?city=New York. If you don't encode the space, some servers will reject the request outright or silently truncate it at the space. Encoding the value first to New%20York avoids this entirely.
Scenario 3 — Debugging a link that "doesn't work": If a colleague sends a link full of confusing % symbols and claims it's broken, decoding it here instantly shows you the actual intended text, which often reveals the real issue was a typo in the original text, not the encoding itself.
Common Characters and Their Encoded Form
| Character | Component Encoding | Full URI Encoding |
|---|---|---|
| Space | %20 | %20 |
| & | %26 | & (unchanged) |
| = | %3D | = (unchanged) |
| ? | %3F | ? (unchanged) |
| / | %2F | / (unchanged) |
| # | %23 | # (unchanged) |
| @ | %40 | @ (unchanged) |
| % | %25 | %25 |
| + | %2B | + (unchanged) |
| : | %3A | : (unchanged) |
| ' | ' (unchanged) | ' (unchanged) |
| " | %22 | %22 |
| < | %3C | %3C |
Common Mistakes to Avoid
- Double encoding. Encoding an already-encoded string turns every existing
%into%25. For example, encoding%20again produces%2520— a URL with this in it will decode back to a literal%20instead of a space, breaking the link. Always check for existing%sequences before encoding. - Using Full URI mode on a single parameter value. As shown in the scenario above, this can silently create extra query parameters instead of escaping the value's own special characters.
- Forgetting to decode when reading logged or stored data. If you save an encoded value to a database and later display it to a user, remember to decode it back to readable text first.
- Confusing URL encoding with HTML encoding. HTML encoding (like
&for&) is a completely different system used inside HTML documents, not URLs — the two are never interchangeable.
Troubleshooting
I get "malformed URI" errors when decoding: This means the text contains a % that isn't followed by exactly two valid hex digits (0-9, A-F) — often from a string that was manually edited, truncated, or already partly decoded. Check for stray % characters that aren't part of a real encoded sequence.
My decoded text shows garbled characters instead of Urdu/Arabic/Hindi text: This usually means the original text was encoded using a different character encoding than UTF-8 (rare today, but possible with very old systems). This tool assumes standard UTF-8, which covers virtually all modern URLs.
My link works in one browser but not another: This is almost never actually an encoding problem — modern browsers all follow the same percent-encoding rules. Check instead for a redirect issue or a server-side validation difference.
FAQs
Why does my URL show %20 in some places and a literal + in others for spaces?
Both represent a space, but from two different eras of the standard — %20 is the general-purpose form used everywhere in a URL, while + is a special case specifically inside query strings, inherited from older HTML form submissions (application/x-www-form-urlencoded). This tool always produces the standard %20 form.
What happens if I decode text that was never encoded?
Nothing changes — decoding text with no % sequences simply returns it exactly as-is, since there's nothing to convert.
Can I encode emojis?
Yes. Emojis are valid Unicode characters and get converted into their multi-byte UTF-8 percent-encoded sequence, just like any other non-ASCII character.
Why is my encoded output so much longer than the original text?
Non-English characters (Urdu, Arabic, Chinese, emojis, etc.) typically take 2-4 bytes each in UTF-8, and each byte becomes its own 3-character %XX sequence — so a single Urdu character can expand into 6-12 characters once encoded. This is completely normal.
Should I encode the whole URL or just parts of it?
Only encode the parts built from user input or freeform text — like a search term — using Component mode. Encoding an entire well-formed URL with Component mode would break it by escaping its own slashes and question marks.
Is URL encoding the same as encryption?
No — encoding is not security. Anyone can decode a percent-encoded string instantly, as this tool demonstrates. Never rely on URL encoding to hide or protect sensitive information.
Related Tools
JSON Formatter · Regex Tester · Base64 Encoder · What Is My IP Tool