Free URL encoder & decoder

URL encoding — formally called percent-encoding — is the scheme defined by RFC 3986 for representing characters inside a URL that would otherwise be unsafe, ambiguous, or simply not allowed. A URL can only contain a limited set of ASCII characters. Anything outside that set — a space, an ampersand inside a value, an emoji, a letter with an accent — has to be converted into a form the URL spec permits.

Percent-encoding does this by taking the UTF-8 byte value of a character and writing it as a percent sign followed by two hexadecimal digits. The space character, for example, is byte 0x20, so it becomes %20. A character that needs multiple UTF-8 bytes, like é (0xC3 0xA9 in UTF-8), becomes a sequence of percent-triplets: %C3%A9. This is why encoding and decoding a URL is a byte-level operation, not just a character substitution — the tool above uses your browser's UTF-8-aware encodeURIComponent/decodeURIComponent functions under the hood so multi-byte characters and emoji round-trip correctly.

You'll run into percent-encoding constantly when building query strings, sharing links with special characters, working with REST APIs, debugging webhooks, or reading raw server logs where every non-ASCII character shows up as a string of %XX codes.

JavaScript ships two built-in encoding functions, and mixing them up is one of the most common URL bugs. Both percent-encode unsafe characters, but they disagree on how to treat characters that are structurally meaningful in a URL — things like /, ?, &, =, and #.

• encodeURIComponent (the “Component” scope above) escapes everything that isn't a letter, digit, or one of - _ . ! ~ * ' ( ). That includes /, ?, &, =, and #. Use it whenever you're encoding a single piece of data — a query parameter value, a path segment, a form field — that will be inserted into a URL.
• encodeURI (the “Full URL” scope above) assumes the input is already a complete, structurally valid URL. It escapes spaces and unsafe characters but leaves reserved characters alone — /, ?, &, =, #, and : pass through untouched, because encoding them would break the URL's structure. Use it when you have a whole URL and only want to fix unsafe characters without corrupting its syntax.

The practical rule of thumb: if you're building a query string value by hand — for example a UTM parameter or a search term — encode it with encodeURIComponent before inserting it. If you already have a complete URL and just need to make it safe to paste somewhere, use encodeURI so you don't mangle its ://, ?, and & structure.

RFC 3986 splits ASCII characters into a few buckets. Unreserved characters never need encoding because they have no special meaning in a URL. Reserved characters are meaningful delimiters — they only need encoding when they appear literally inside a value rather than as part of the URL's structure.

Whether a reserved character needs encoding depends entirely on context. A / in the path separates directories, so it should stay literal there — but a / inside a filename that's being passed as a query value has to be encoded to %2F, or the URL parser will misread it as a path separator. This is exactly why encodeURIComponent escapes reserved characters and encodeURI does not: the former assumes you're building one component, the latter assumes you already have valid structure.

You'll see spaces represented two different ways depending on where they appear:

• %20 is the strict percent-encoding of a space and is valid anywhere in a URL — the path, the query string, or a fragment. This is what encodeURIComponent and encodeURI both produce.
• + is a legacy convention from the application/x-www-form-urlencoded content type used by HTML forms and defined by the WHATWG URL Standard. Inside a query string specifically, a literal + is interpreted as a space by form-decoding libraries — including JavaScript's own URLSearchParams, which is why the inspector panel above decodes + as a space when it parses query parameters.

The catch: + only means “space” inside a query string that is being parsed as form-encoded data. In the path portion of a URL, or when decoded with decodeURIComponent instead of URLSearchParams, a literal + stays a plus sign — it is not automatically converted to a space. Mixing up which decoder you're using is a classic source of bugs where a + in a name or email address either turns into an unwanted space or a real space fails to become a +. When in doubt, encode spaces as %20 — it is unambiguous in every context, while + only works inside query strings.

A URL is made of several distinct parts, and percent-encoding rules differ slightly depending on which part a character sits in:

• Scheme (https:) — restricted to letters, digits, +, -, and .; never percent-encoded in practice.
• Authority (user:pass@host:port) — the host portion uses its own encoding (Punycode for internationalized domain names) rather than percent-encoding.
• Path (/blog/my-post) — segments are separated by literal / characters; a literal slash inside a segment (say, a filename) must be encoded to %2F or it will be read as a new segment.
• Query string (?key=value&key2=value2) — pairs are separated by & (or sometimes ;) and keys from values by =; any of those three characters appearing literally inside a key or value must be encoded, which is exactly what the URL inspector panel above handles for you automatically when it rebuilds the URL.
• Fragment (#section-2) — everything after # is only used by the browser, never sent to the server, but still follows the same percent-encoding rules for any character outside the safe set.

This is also why the URL inspector on this page splits a pasted URL into protocol, host, and path before showing the query string as an editable table: each of those pieces has different rules, and editing the query string safely means encoding only the parts that need it while leaving the rest of the URL's structure untouched.

1. Choose Encode or Decode. Encode turns readable text into percent-encoded form; Decode reverses a percent-encoded string back into readable text.
2. Pick a scope. Use Component for a single value you're inserting into a URL (a query param, a path segment). Use Full URL when you already have a complete URL and want to encode or decode it without breaking its ://, ?, and & structure.
3. Type or paste into the left box — the result updates instantly on the right as you type.
4. Copy, swap, or clear. Copy the result to your clipboard, swap the input and output to chain another transformation, or clear the box to start over.
5. Inspect a full URL. Paste a complete URL into the URL inspector panel to see its protocol, host, and path, and to edit its query parameters as a table — the rebuilt URL updates live and you can copy it with one click.

• Double-encoding. Running an already-encoded string through the encoder again turns %20 into %2520. If your decoded output still contains %XX sequences, decode it a second time.
• Using encodeURI on a single value. Because it leaves & and = untouched, encoding a query value with encodeURI instead of encodeURIComponent can silently create extra parameters or corrupt the query string.
• Forgetting non-ASCII characters. Accented letters, curly quotes, and emoji all need percent-encoding — a URL with a literal é or — pasted in unencoded will break in some clients even though it looks fine in a browser address bar.
• Assuming + always means space. As covered above, + only decodes to a space in form-encoded query strings — not in path segments, and not with decodeURIComponent.
• Malformed percent sequences. A stray % not followed by two valid hex digits (like 50% off) will throw a URIError when decoded — the tool above surfaces this as a friendly error instead of failing silently.

• Developers encode query parameters, debug malformed redirect URLs, and decode raw request logs to see what a client actually sent.
• Marketers build and audit UTM-tagged campaign links with spaces, ampersands, or special characters in campaign names, and verify tracking links survive being pasted into email or ad platforms unchanged.
• SEOs check that internal links and canonical tags use correctly encoded, non-duplicated URLs, since an encoded and unencoded version of the same URL can otherwise be treated as two different pages.
• QA and support teams decode percent-encoded strings from bug reports, webhook payloads, and server error logs to see what was actually sent, without needing to spin up a script.
• API integrators confirm that path and query parameters are encoded correctly before sending a request, and decode responses that echo encoded values back.
• Data analysts clean up exported URLs from analytics platforms where tracking parameters and search terms show up percent-encoded.

The same %XX scheme shows up outside the browser address bar too, which is one reason a general-purpose encoder/decoder is worth bookmarking rather than reaching for a language-specific snippet every time:

• HTML form submissions. When a browser submits a form with method GET, every field name and value is percent- and form-encoded into the query string of the resulting request.
• Email links (mailto:) and deep links. Subject lines, bodies, and custom app URI schemes all rely on the same encoding so spaces and punctuation survive being embedded in a link.
• Webhook and API payloads. Some APIs accept application/x-www-form-urlencoded bodies instead of JSON, which use the identical percent-encoding (plus the +-for-space convention) as a query string.
• Server and CDN logs. Raw access logs frequently record the request path exactly as it arrived on the wire — still percent-encoded — so decoding it is often the fastest way to see the real search term or file name a visitor requested.