A URL encoder with the right escapes for the right context.
Encode and decode strings using the three flavors that actually exist in the wild — full URI, single component, and `application/x-www-form-urlencoded`. Live query-string parser included. Everything runs locally; your input never reaches a server.
0 charsYour input never leaves your machine. The encoder, the decoder, and the query parser all run in this browser tab using `encodeURI`, `encodeURIComponent`, `URL`, and `URLSearchParams` — all built into the engine. We never see your URL or text, and the page makes no network calls related to your input.
Three encoders for the three jobs, plus a parser that earns its keep.
The features people use when wrestling with URLs — the right encoder for the right slot, a query parser, and precise error messages — surfaced without sign-up, without ads, and without dropping your URLs on a server.
Choose between Full URI (preserves `:/?#[]@`), Component (encodes everything reserved), and Form (component plus `+` for space). Most bugs in the wild are using the wrong one.
When the input parses as a URL with a query string, a key/value table appears under the editor — every key and value already decoded, with one-click copy on each cell.
Decoding accepts standard `%20` whitespace and form-style `+` interchangeably, so you can paste a value from anywhere — query string, form body, log line — without flipping a toggle.
Emoji, accented characters, CJK, and astral-plane code points all encode and decode cleanly — `encodeURIComponent` is UTF-8 native by spec.
Every keystroke triggers a re-encode or re-decode. No Generate button, no spinner — just immediate output.
Malformed `%XX` sequences (the only failure mode for `decodeURIComponent`) surface with the exact byte position and the offending sequence — no guessing.
One click for the system clipboard or a `.txt` file. Per-cell copy buttons in the query parser table for grabbing a single value out of a long URL.
Use it anonymously, on as many URLs as you want. No account, no cookies, no usage counter. Inspect the network tab — there is nothing outbound to inspect.
For every URL that needs to survive transit.
Stuffing a value with `&`, `=`, spaces, or quotes into a query string requires Component encoding — anything less and the receiver mis-parses the request. Encode here, paste into the URL, ship.
Path segments with slashes, colons, or non-ASCII have to be Component-encoded so the routing layer treats them as a single segment, not multiple. Common when the segment is user-provided content like an email or a slug with punctuation.
Server logs often contain percent-encoded redirect URLs. Paste in to read them like a human, then check whether the encoding is correct or if some upstream double-encoded it.
A `%2520` in the wild means `%20` was encoded a second time — usually a CMS or proxy that ran encoding twice. Decode once to confirm; decode again to see the original.
Form posts use `+` for spaces (not `%20`) — that is the Form flavor. Encode each field value here before joining with `&`, and the body will round-trip through any HTTP form parser.
When inserting user-provided text into a URL, Component-encode it first to neutralize any reserved characters that could otherwise break the URL or open an XSS vector. Especially relevant for redirect parameters.
URL encoding, the plain answers.
Use **Full URI** when encoding an entire URL string that is already structurally valid — it preserves the reserved characters that give a URL its shape (`:`, `/`, `?`, `#`, `[]`, `@`). Use **Component** when encoding a single value that will be inserted into a URL — query value, path segment, fragment. Use **Form** for `application/x-www-form-urlencoded` bodies and for query strings produced by HTML forms (the only difference from Component is that spaces become `+` instead of `%20`).
Historical: HTML forms inherited the convention from older CGI implementations, and the spec for `application/x-www-form-urlencoded` (now in the URL Standard) made it official. Most server-side parsers accept both — `URLSearchParams` does — but the canonical form is `+`. Outside of form submissions, prefer `%20`.
You get visible double-encoding: a single `%20` (space) becomes `%2520` (the `%` itself gets encoded to `%25`). Most parsers do not auto-double-decode, so the receiver sees `%20` as a literal string instead of a space. To diagnose: decode once and check whether the result still has `%XX` sequences — if yes, it was double-encoded.
RFC 3986 defines an 'unreserved' set — letters, digits, `-`, `.`, `_`, `~` — that never need encoding because they have no special meaning anywhere in a URL. `encodeURIComponent` leaves these alone; this is correct and round-trips through every parser. The 'reserved' set (`:/?#[]@!$&'()*+,;=`) is what changes between flavors.
No. Every byte of the encode/decode/parse pipeline runs in this browser tab. The page makes no network calls related to your input. Open DevTools → Network while you paste, and nothing outbound appears.
Effectively no. Browsers can encode multi-megabyte strings without issue. Real-world limits show up downstream — most servers cap a single URL at 8 KB total, and `Cookie` / `Authorization` headers cap lower. The encoder will not stop you from producing a 100 KB string; the receiver might.
Building APIs with first-class URL routing?
Sign up for the free tier and you get $100 in credits, plus VMs, managed databases, object storage, and zero-config autoscaling across four regions.