About URL Encode

URL encoding (percent-encoding, RFC 3986) represents characters that are unsafe or reserved in URLs as % followed by two hex digits of their UTF-8 bytes: a space becomes %20, & becomes %26, ก becomes %E0%B8%81. Without it, user input containing &, =, #, or ? silently changes the meaning of your URL — splitting parameters, truncating fragments, and producing bugs that only appear when someone types the wrong (right) character.

This tool encodes text the way encodeURIComponent does in JavaScript: every reserved character is escaped, making the output safe to drop into a query-string value, a path segment, or a form field. It runs entirely in your browser.

How to use URL Encode

  1. Enter or paste the input in the text area.
  2. Click Convert to encode or decode.
  3. Copy or download the result.

Example

Input

Your input or data here

Output

Result will appear here after running the tool

Reserved vs unreserved: what gets encoded and why

RFC 3986 splits characters into unreserved (A–Z, a–z, 0–9, -, _, ., ~) — always safe, never need encoding — and reserved (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) — characters that have structural meaning in a URL. Whether a reserved character needs encoding depends on where it appears: a / in a path is structure, but a / inside a query value is data and must become %2F.

This is why 'just encode the whole URL' is wrong. Encoding a complete URL turns its structure (:// and /) into data, breaking it. The correct pattern: build the URL from parts, encoding each dynamic value individually, exactly what encodeURIComponent-per-parameter or URLSearchParams does.

The + vs %20 space problem

There are two historical ways to encode a space. Percent-encoding (RFC 3986) uses %20 and is correct everywhere in a URL. Form encoding (application/x-www-form-urlencoded, used by HTML forms) uses + for spaces — but only in that context. The collision: a + in a query string is decoded as a space by form parsers, so a literal plus sign (phone numbers like +66..., timezone offsets, Base64 values) must be encoded as %2B.

Symptoms of getting this wrong are unmistakable: phone numbers arriving with a leading space instead of +, and Base64 tokens failing to decode because their + turned into spaces. When a value must survive a query string, %2B is not optional.

Unicode: what %E0%B8%81 means

Percent-encoding operates on bytes, not characters. Non-ASCII text is first encoded to UTF-8, then each byte is percent-encoded: é (U+00E9) → 0xC3 0xA9 → %C3%A9; Thai ก (U+0E01) → three bytes → %E0%B8%81. One character can therefore become up to twelve encoded characters (4-byte emoji). This byte-level view explains both why encoded URLs balloon in size and why decoding with the wrong charset yields mojibake.

Common errors and how to fix them

Query parameter value gets cut off at an & or #

Cause: The raw value contained & (parameter separator) or # (fragment start) without encoding.

Fix: Encode the value: & → %26, # → %23. In code, never concatenate raw user input into URLs — use URLSearchParams.

Plus signs arrive as spaces on the server

Cause: + means space in form-encoded query strings; a literal plus must be %2B.

Fix: Encode + as %2B when it is data (phone numbers, Base64). This tool does that automatically.

The URL was encoded twice (%2520 appears)

Cause: %20 was encoded again — % itself became %25. Typical when one layer encodes and another 'helpfully' encodes again.

Fix: Encode exactly once, at the point where the value enters the URL. If you see %25XX patterns, decode twice to recover, then fix the duplicate encoding layer.

Slashes in a path parameter break routing

Cause: A value like a/b was inserted into a path segment; the router split it at the /.

Fix: Encode / as %2F for path-segment data — and verify your server doesn't decode before routing (some frameworks reject %2F in paths for that reason).

Tips and best practices

  • Encode components, not whole URLs. If you must sanitize a full URL, JavaScript's encodeURI exists — it preserves structure characters — but component-wise construction is the reliable approach.
  • Unreserved characters (letters, digits, - _ . ~) never need encoding; encoding them anyway (%41 for A) is legal but wasteful and can break cache keys and signatures that compare URLs textually.
  • OAuth signatures, S3 presigned URLs, and webhook verifications are case-sensitive about hex (%2F vs %2f) and strictness. When a signature mismatch is mysterious, byte-compare the encoded strings.
  • For decoding what a server actually received, pair this tool with URL Decode — round-tripping a problematic value exposes where the corruption happened.

Frequently asked questions

Should I encode a full URL or just parts of it?
Parts. Encoding a full URL destroys its structure (:// and / become data). Build URLs from components, encoding each dynamic value — that is exactly what encodeURIComponent and URLSearchParams are for.
Space: %20 or +?
%20 is correct everywhere. + means space only in application/x-www-form-urlencoded contexts (HTML form submissions, query strings parsed by form rules). If you need a literal +, encode it as %2B.
Why does one Thai/emoji character become many %XX groups?
Encoding works on UTF-8 bytes. Thai characters are 3 bytes (three %XX groups); emoji are usually 4. This is standard behavior, not corruption.
What characters never need encoding?
The RFC 3986 unreserved set: letters, digits, hyphen, underscore, period, tilde. Everything else is either reserved (structural) or unsafe and should be encoded when used as data.
Is this equivalent to JavaScript's encodeURIComponent?
Yes, in behavior: it encodes all reserved characters including & = ? # / +, making values safe for query strings and path segments. encodeURI, by contrast, preserves URL structure and is for whole URLs.
Is my input uploaded?
No. Encoding runs entirely in your browser.

Embed this tool

Add URL Encode to your own site, blog post, or internal docs — free, no signup. The widget runs entirely in your visitors' browsers, same as it does here.

Related tools