Encode and decode URL components, query strings, and full URLs online. Handles percent-encoding and special characters with instant results.
URL Encoder / Decoder encodes and decodes locally, so nothing you paste is ever transmitted.
It's one of the free
Encoding & Decoding Tools
on UseToolSuite.
Use it below, then scroll down for a step-by-step guide, answers to common questions, and related tools.
What is URL Encoder / Decoder?
URL Encoder / Decoder is a free online tool that converts text into a
URL-safe format (percent-encoding) and decodes percent-encoded strings
back to their original form. URLs can only contain a limited set of
ASCII characters; special characters like spaces, ampersands, question
marks, and non-Latin characters must be percent-encoded to be
transmitted correctly. This tool supports both component encoding
(encodeURIComponent) and full URL encoding (encodeURI), along with
URL parsing and double decoding for multi-layered encoded strings.
When to use it?
Use the URL Encoder whenever you need to safely include special
characters in query strings, path segments, or fragment identifiers.
It's particularly helpful when building API request URLs with dynamic
parameters, debugging encoded URLs from server logs or analytics
platforms, or preparing deep links that contain non-ASCII characters.
The URL parser breaks any URL into its components (protocol, host,
path, query parameters) for easy inspection.
Common use cases
Web developers and API engineers commonly use URL Encoder to construct
safe query parameters for REST API calls, decode tracking URLs from
marketing campaigns and analytics tools, encode user-generated content
before appending it to URLs, debug routing issues caused by improperly
encoded characters, and prepare redirect URLs for OAuth flows. The
double decode feature handles multi-layered encoding often found in
redirect chains and analytics tracking URLs.
Percent-encoding rules explained
URL encoding (percent-encoding) replaces unsafe characters with a percent sign followed by two hexadecimal digits representing the character's byte value. For example, a space becomes %20, an ampersand becomes %26, and a forward slash becomes %2F. Multi-byte UTF-8 characters produce multiple percent-encoded triplets — the Japanese character 日 encodes as %E6%97%A5 because it requires 3 bytes in UTF-8. RFC 3986 defines which characters are unreserved (never need encoding): A-Z, a-z, 0-9, hyphen, period, underscore, and tilde.
encodeURI vs encodeURIComponent in JavaScript
JavaScript provides two encoding functions with different scopes. encodeURI() encodes a complete URL but preserves characters that have special meaning in URLs: : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Use it to encode an entire URL string. encodeURIComponent() encodes everything except A-Z, a-z, 0-9, and - _ . ~ ! * ' ( ). Use it for encoding individual query parameter values. The most common mistake is using encodeURI() on a parameter value, which fails to encode & and = and breaks the query string.
Reserved vs unreserved: what actually needs encoding
RFC 3986 splits characters into unreserved — letters, digits, -, ., _, ~ — which never need encoding, and reserved — : / ? # [ ] @ ! $ & ' ( ) * + , ; = — which carry structural meaning and must be encoded when used as data. The subtlety is “when used as data”: a / separating path segments stays raw, but a / inside a single segment (a filename) must become %2F. Encoding is therefore per-component, never applied blindly to a whole assembled URL — encoding the full URL would destroy the very separators that make it a URL.
Building query strings that don’t break
Each key and each value must be encoded independently before assembly with = and &. The classic failure: a value containing & or = (a song title, a search phrase) injected raw splits the query string and silently truncates data. In JavaScript, URLSearchParams handles this correctly and is preferred over manual encodeURIComponent chains; in URLs you craft by hand, paste each value through this encoder separately. Watch for # especially — unencoded, it ends the query string and starts a fragment that never reaches the server.
Non-ASCII text: UTF-8 first, then percent
Modern encoding is two steps: text becomes UTF-8 bytes, each byte becomes %XX. Turkish ş is %C5%9F, one character but two encoded bytes. Legacy systems that encoded with ISO-8859 charsets produce different sequences for the same character — the root cause of mojibake in old query strings. International domain names take a different path entirely: the hostname uses Punycode (bücher.de → xn--bcher-kva.de), while only paths and queries use percent-encoding.
Spotting encoding bugs in the wild
Symptoms map to causes: literal %20 displayed to users means decoded-never; %2520 in logs means encoded-twice; broken parameters after a user typed & means encoded-never on input; mojibake like ç for ç means UTF-8 bytes decoded as Latin-1. Paste the suspect string here and decode step by step — each decode peels one layer, and the layer count tells you which component in your pipeline is misbehaving.
How helpful was this tool?
Click to rate
Awesome! Glad it helped.
We don't have a marketing budget. The best way to support this free tool is by sharing it with other developers!
Help us improve!
Sorry it didn't meet your expectations. We're always looking to make these tools better. What was missing or broken?
Open GitHub Issue