Encode URLs and read query strings without guessing
Percent-encoding has more than one correct answer depending on context, and a query string with a dozen parameters is unreadable in raw form. This tool encodes a full URL or a single component, and parses any query string into a table.
- Modes
- Full URL or component
- Parser
- Query to table
- Encoding
- UTF-8
How to use it
- Paste the URL or the fragment A whole URL, a single query parameter value, or a raw query string all work. The parser mode takes a query string on its own.
- Encode or decode Encoding percent-escapes reserved characters. Decoding turns %20 back into a space and %26 back into an ampersand.
- Read the parsed parameters The parser shows every parameter in a table with its decoded name and value, and flags repeated keys that would otherwise silently overwrite each other.
Questions people ask
When should I encode a whole URL versus a single component?
Encode a single component when you are inserting a value into a URL you already have. Encode a whole URL when it is going into another URL, because its own reserved characters would otherwise be interpreted as structure by the outer URL.
Should spaces be %20 or +?
In a query string built with form encoding, a space is +. In a path, in a fragment, or in anything you want to survive being copied between systems, %20 is the safe choice because + can be a literal plus.
Why does my parser show duplicate parameters?
Because the query string genuinely contains them. Most frameworks keep only the last occurrence of a repeated key, which means the first value is lost without a trace. A repeated key like tags[] is a deliberate array encoding and is fine.
Does it decode plus signs as spaces?
Only in query-string context, where that is the convention. Path segments keep their literal plus signs.
Can I encode a JSON payload for a URL parameter?
Yes, but compress it first if you can. A JSON payload is usually longer than the limit most servers accept, and base64 does not shrink it. The base64 tool in this toolbox is the right companion for opaque values.
Is the encoding reversible for non-ASCII characters?
Yes. UTF-8 bytes are escaped, so a character like é becomes its multibyte percent-encoded form and decodes back to the same character.
Reference
Query string parsing
| Raw parameter | Decoded name | Decoded value |
|---|---|---|
| `q=blue%20shoes` | `q` | `blue shoes` |
| `redirect=https%3A%2F%2Fa.com%2Fb` | `redirect` | `https://a.com/b` |
| `tags%5B%5D=a&tags%5B%5D=b` | `tags[]` | `a` (and `b` — a repeated key) |
Details that catch people out
Unreserved characters (letters, digits, hyphen, underscore, dot and tilde) never need escaping. Everything else depends on context: a path segment allows different characters than a query value, and a fragment follows yet another set. Encoding the whole URL when you only meant one component is a common and confusing mistake.
A + in a query string means a space in the widely used form-encoding convention, but a literal + in a path means a literal plus. Decoders that treat + as a space everywhere will corrupt path segments.
URLs carry more than addresses
Reset tokens, session identifiers, OAuth codes and email campaign parameters all travel inside a URL. Parsing one through a remote service means transmitting that token to a third party, where it is very likely to end up in an access log.
- No server sees the URL you are inspecting.
- Full-URL mode leaves the scheme and host untouched and only escapes the path, query and fragment.
- The parser flags duplicate query keys, which silently drop data in most frameworks.
- UTF-8 aware, so multibyte characters encode correctly.
Last reviewed 2026-10-06. Every tool on DevSnap runs entirely in your browser, so whatever you paste here never reaches a server.