Related tools
Why use a URL encoder and decoder?
Browsers, servers, and caches treat certain characters as structure—spaces, ampersands, hashes, and non-ASCII text all need escaping when they are data rather than syntax. A dedicated tool helps you preview the exact string an HTTP client will send.
Benefits of correct URL encoding
- Safe transmission: Reserved characters in user content stop breaking parsers that split paths, queries, and fragments.
- Unicode support: UTF‑8 bytes can be represented as % sequences so international text survives plain-ASCII transports.
- Predictable APIs: Aligning with RFC 3986 reduces mismatches between front-end code, mobile apps, and backend frameworks.
- Fewer 400 errors: Properly encoded parameters are less likely to be rejected by strict gateways or reverse proxies.
- Easier debugging: Compare your hand-built string with what encodeURIComponent would produce before you ship a hotfix.
How URL encoding works
Percent-encoding rewrites each byte that must not appear literally in a URL segment as %HH, where HH is hexadecimal. Which characters stay literal depends on whether you are protecting a whole URL or an individual component.
Modes in this tool
- Component mode: Mirrors encodeURIComponent / decodeURIComponent—ideal for keys, values, path segments, or anything you will paste into a query string.
- Full URL mode: Mirrors encodeURI / decodeURI—intended for strings that still contain scheme, host, slashes, and query punctuation after transformation.
- Live transform: Every edit runs through the selected pair so you immediately see malformed input or double-encoding mistakes.
Facts worth remembering
Small details—like plus signs in form posts versus true percent-encoding—trip up teams when frameworks disagree.
Quick reference
- Space is commonly %20 in query strings; HTML forms may use + in application/x-www-form-urlencoded bodies.
- Only unreserved characters (letters, digits, -._~) may appear unencoded in strict component encoding.
- Double-encoding (encoding an already encoded string) produces longer URLs and can confuse servers.
- decodeURIComponent will throw on % followed by incomplete hex; fix the source before decoding.
- Internationalized domain names use Punycode in DNS; URL encoding handles the path and query, not the ACE hostname conversion.
Best practices
Encode at the boundary where untrusted text becomes part of a URL, and decode once when you treat it as data again.
- Encode each query value individually instead of encoding the entire URL twice.
- Log raw user input separately from the encoded string when debugging analytics or redirects.
- Prefer HTTPS links when sharing encoded URLs that contain sensitive tokens.
- Validate decoded output before injecting it into HTML to avoid XSS from malicious links.
- Unit-test both modes if your product supports deep-linking from email or SMS templates.
Ideal use cases
- Web development: Build search filters, UTM parameters, and OAuth redirect URIs with confidence.
- API integration: Match SDK behavior when documentation references RFC 3986 percent-encoding.
- QA and support: Reproduce customer URLs without guessing which characters were escaped.
- Documentation: Show exact before/after examples for partner integrations.
- Migration scripts: Compare legacy escaping rules with modern browser functions.
Frequently asked questions
What is the difference between component and full URL encoding?
Component encoding (JavaScript encodeURIComponent) applies percent-encoding to almost every reserved character, which is what you want for individual query keys or values. Full URL encoding (encodeURI) leaves delimiters such as : / ? & = so an entire URL string remains navigable after encoding.
When should I use decodeURIComponent vs decodeURI?
Match the encoder you used: decodeURIComponent for single components, decodeURI for a string that still needs to look like a full URL with slashes and query separators.
Is my data sent to your servers?
No. Encoding and decoding run entirely in your browser; nothing is uploaded.
What does “percent encoding” mean?
Bytes that cannot appear raw in a URL are written as % followed by two hex digits (for example, a space becomes %20). That is what RFC 3986 calls percent-encoding.
Why did decoding show an error?
Malformed percent sequences (odd number of hex digits, invalid UTF-8 after decoding, or mixing modes) can throw. Double-check the string and try the other encoding type if you encoded a full URL as a component.