URL Encode/Decode

URLs only allow a limited set of characters in their raw form. Spaces, ampersands, equals signs, non-ASCII text, and many symbols must be converted into percent-encoded sequences before they can travel safely as part of a path or query value. This tool applies standard percent encoding so you can prepare a string for a link or recover the original text from an encoded parameter. Use it when building search URLs, debugging referral links, preparing mailto parameters, or inspecting what a browser actually sent. Encoding only the dynamic portion of a URL—not the entire address—keeps schemes, hosts, and reserved separators intact while still protecting the payload.

Informational only; verify critical results independently.

How to use

  1. Paste only the text that will become a path segment or query value—not the full https:// address if you want to avoid damaging reserved characters.
  2. Choose Encode to turn spaces, punctuation, and Unicode into percent sequences such as %20 or multi-byte UTF-8 forms.
  3. Copy the encoded result into your query string, redirect builder, or API client as a single parameter value.
  4. When you already have a percent-encoded string from logs or analytics, paste it and choose Decode to read the original human text.
  5. If you see plus signs standing in for spaces from old form submissions, normalize them to %20 before decode if your source used that convention.
  6. Encode email addresses, product titles, or filter names individually so ampersands and equals signs do not split the query into extra keys.
  7. After a round trip of encode then decode, confirm the plain text matches your source to catch double-encoding or truncated paste errors.
  8. Avoid encoding an already-encoded string a second time unless you intentionally need nested encoding for a proxy or nested parameter.
  9. Keep scheme, host, path separators, and the ? & = structure of the URL outside of the text you encode so navigation still works.
  10. Treat this as a drafting aid: production systems should encode with the same library conventions your backend expects.

Examples

  • Encode hello world for a search query → hello%20world.
  • Encode a=b&c=d as one parameter value → a%3Db%26c%3Dd so it does not invent extra query keys.
  • Decode %E4%BD%A0%E5%A5%BD → 你好 (UTF-8 Chinese greeting).
  • Encode user@example.com for a mailto or nested query value → user%40example.com.
  • Encode price=10.99 for a product deep link value → price%3D10.99.
  • Encode café menu → caf%C3%A9%20menu with UTF-8 percent bytes for é.
  • Decode %2Fapi%2Fv1%2Fusers when you need the literal path string /api/v1/users as a value, not as real path segments.
  • Encode well-known → well-known (hyphen may stay unescaped) while space still becomes %20.
  • Decode a long tracking parameter like utm_campaign=spring%20sale%20%E2%9C%85 to read spring sale ✓.
  • Encode 100% match carefully: the percent itself becomes %25 so decode does not misread later digits as escapes.

FAQ

What is percent encoding?
Percent encoding replaces unsafe or reserved characters with a percent sign followed by two hexadecimal digits representing a byte. In modern web stacks that usually means UTF-8 bytes. The result can sit inside a URL without being mistaken for structure such as a path slash or a query delimiter.
Should I encode the entire URL or just part of it?
Encode only the dynamic piece: one query value, one path segment, or one header fragment. Encoding a complete URL turns colons and slashes into %3A and %2F, which breaks browsers and scrapers that expect a real address. Nest parameters carefully when one URL contains another.
Why do some systems use + instead of %20 for spaces?
Older application/x-www-form-urlencoded forms historically used + for space. Strict percent encoding and many encodeURIComponent-style APIs use %20 instead. If decode looks wrong, try replacing + with %20 first, then decode again so spaces come back as spaces.
Why did my slash become %2F?
A literal slash inside a value must not create extra path segments, so it is encoded as %2F. That is correct when the slash is data. If you meant real path levels, keep those slashes outside the string you encode and only encode each segment’s name.
How are Unicode characters and emoji handled?
They are converted to UTF-8 bytes and each byte is percent-encoded. A check mark might appear as %E2%9C%85. Decoding those sequences restores the original character when the payload is valid UTF-8 percent-encoding.
What is double-encoding and how do I spot it?
Double-encoding happens when %20 is encoded again into %2520. The text still looks “encoded” but a single decode only peels one layer. Decode once, inspect the result, and stop when you see plain text rather than more percent sequences—unless your architecture truly nests layers.
Why does decode produce mojibake or weird characters?
The input may be truncated, mixed with HTML entities, or encoded with a non-UTF-8 legacy charset. Confirm you pasted a complete percent-encoded value and that the producing system used UTF-8. Partial hex pairs or stray % characters also confuse decoders.
Is this the same as encodeURI versus encodeURIComponent?
Conceptually this tool follows component-style encoding: characters that are meaningful in URLs, such as &, =, and /, are escaped so they can live inside a single parameter. Full-URI helpers leave more characters alone so they can form a complete address. Match whichever convention your framework documents.
Can I use this for path segments that include spaces or accents?
Yes. Encode each segment’s name separately, then join with real slashes between segments. That pattern keeps directory structure readable while still sending international characters safely to servers that expect UTF-8 percent-encoding.
Does encoding hide or encrypt sensitive data?
No. Percent encoding is reversible by design and is only a transport encoding. Anyone can decode the value. Use HTTPS and proper access control for secrets; never treat URL encoding as confidentiality.
When should I leave a character unencoded?
Unreserved characters such as letters, digits, hyphen, period, underscore, and tilde are often left as-is. Reserved characters stay unencoded only when they play their structural role—for example the ? that starts a query string. When in doubt for a value, encode it.
Is my text sent to a server when I use this tool?
No. Encoding and decoding run in your browser. We do not store the strings you paste. Still avoid pasting live production secrets into any page you do not trust.

Formula / Method

Percent encoding maps each unsafe character to UTF-8 bytes, then represents each byte as %HH where HH is two hex digits. For example, a space (0x20) becomes %20, and & (0x26) becomes %26. Decoding reverses the process: each %HH sequence becomes a byte, and the byte sequence is interpreted as UTF-8 text. Encode only values that need to travel as data inside a URL; leave reserved separators that define structure alone.

Assumptions & Limitations

This tool targets common browser-style percent encoding for text values. It does not implement every historical form-encoding quirk, IDN hostname punycode conversion, or server-specific escape rules. Results are for drafting and debugging; confirm against your language runtime or API client for production. Decoding invalid or truncated sequences may fail or show unexpected characters.

Related guides

Related tools

Last updated: 2026-07-13

← Back to Text Tools