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 without an account, on as many URLs as you want, and there is no usage counter. The only cookies this site sets are two language cookies, and neither identifies you. 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.