Encode text or URLs to percent-encoded format instantly. Standard, strict RFC 3986, form-encoded, or path-aware variants. No signup, no upload.
Upload a text file to URL-encode or decode it. Files are processed entirely in your browser — nothing is uploaded to a server. Maximum size: 10 MB.
URL encoding (also called percent-encoding) converts characters that aren’t safe in URLs into a %XX hex sequence representing the byte values. It’s defined in RFC 3986, and it’s what lets URLs carry spaces, accented letters, emoji, and reserved characters like & and ? without breaking the URL syntax.
The tool above uses your browser’s native encodeURIComponent and decodeURIComponent under the hood, with extra controls for character set, line-by-line processing, and form-encoded variants.
Drop your URL-encoded string, a full URL, or plain text into the input area.
Decode to read it; encode to make text URL-safe. Live mode runs as you type.
Result appears instantly. Copy with one click, or share via a clean URL.
URL encoding (or percent-encoding) is a scheme defined in RFC 3986 that lets URLs carry characters that would otherwise be unsafe or have special meaning. A space becomes %20, a colon becomes %3A, a question mark becomes %3F. Every non-ASCII byte is also percent-encoded so the URL stays inside the ASCII set, which is what HTTP requires for the request line.
Use encodeURIComponent for individual pieces of a URL — a query parameter value, a path segment, or a fragment. It escapes everything that isn’t a letter, digit, or one of - _ . ! ~ * ' ( ). Use encodeURI only when encoding a complete URL where you want to preserve the structural characters (: / ? # [ ] @ & =) — but you almost never want this in practice, because the structural chars in your input might be data, not structure.
You’ve almost certainly got a character-set mismatch. The encoded bytes were created in (say) Windows-1252 and you’re decoding as UTF-8. Switch the destination character set selector to match the source. If you don’t know the source, try Windows-1252 or ISO-8859-1 first; those are the most common legacy alternatives to UTF-8 on the web.
%20 is the canonical percent-encoded space — works everywhere in a URL. + as a space is a legacy convention from HTML form submissions (the application/x-www-form-urlencoded media type). Browsers send form data with + for spaces in query strings, so most server-side frameworks treat them interchangeably. In path components, however, only %20 is recognised as a space — a literal + means a literal plus sign there.
No. URL encoding is a fully-reversible representation change — anyone can decode it without a key. It’s purely a transport format that lets binary or non-ASCII data travel inside an ASCII URL. Encryption requires a key to reverse and protects content from being read. If you need confidentiality, use HTTPS and never put sensitive data in the URL itself.
Double-encoding happens when something gets URL-encoded twice — a %20 becomes %2520, because the % itself gets encoded as %25. You usually see this when one layer of a system encodes input that’s already encoded. Fix: decode the string twice. Our tool returns the result of one decode pass; just run it through again to undo the second layer.
URL encoding (or percent-encoding) is the format that lets URLs carry text containing characters which would otherwise be unsafe or ambiguous. Specifically, you need to encode anything you stuff into a URL that:
Contains spaces, which break the URL syntax — a space ends the request line in HTTP. Reserved characters like ?, &, #, =, / that have structural meaning in URLs; if these appear inside a query value, the parser would misinterpret them as structure. Non-ASCII characters like accented letters, Chinese ideographs, emoji — URLs are restricted to ASCII at the transport level, so anything outside that range must be encoded as UTF-8 bytes and then percent-encoded.
Common situations where you need to encode: building query parameter values that contain user input, constructing redirect URLs, generating tracking links with arbitrary campaign names, embedding one URL inside another (the inner URL must be encoded), creating cURL commands or API request URLs from terminal-unfriendly input.
Paste your text into the input box. Live mode is on by default — the encoded output appears as you type. The output is ready to paste directly into a URL or query string.
Different parts of a URL have different rules about which characters are safe. The variant selector lets you pick the right one for your use case.
Standard (encodeURIComponent). The default and what you want 90% of the time. Encodes everything except letters, digits, and - _ . ! ~ * ' ( ). Safe for query parameter values and path segments.
Strict (RFC 3986 unreserved only). Encodes more aggressively, including ! ' ( ) *. Use when the destination is paranoid about reserved characters — some servers, signing algorithms (AWS Signature v4, OAuth 1.0a), and legacy systems require strict encoding.
Form (space → +). Encodes spaces as + instead of %20. This is the variant that browsers send when submitting an HTML form via GET. Use when you need to match the exact byte representation a browser would produce, or when the receiving framework parses query strings expecting form-encoded data.
Path-aware. Treats / as a path separator and preserves it literally, encoding only within each path segment. Use when you have a full path like /products/My Item/details and need to encode the spaces but keep the slashes.
Query parameter value: Use standard encoding. Input Hello, World! becomes Hello%2C%20World%21, which you append after ?q=.
Building a search URL: Same as above. https://example.com/search?q= + encoded user input.
Embedding a URL inside another URL: Strict encoding. https://example.com/redirect?to= + entire encoded target URL. The target’s :, /, ?, & must all be encoded so they don’t confuse the outer parser.
OAuth signature base string: Strict encoding. OAuth 1.0a specifies RFC 3986-strict encoding for the signature, including ! ' ( ) *.
HTML form GET submission: Form encoding (space → +). Matches what browsers produce.
Encoding the whole URL when you should only encode a piece. If you encode https://example.com/search?q=hello in its entirety, you get https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello — that’s no longer a valid URL, it’s a percent-encoded blob. Encode only the part that’s user data, not the URL’s structure.
Double-encoding. Encoding something that’s already encoded. A %20 becomes %2520, because the % itself gets encoded as %25. Symptom: the receiver shows literal %20 in the output instead of a space. Fix: decode the input first, or check whether your framework is auto-encoding behind your back.
Using + for spaces in path components. Path components don’t treat + as a space — only query strings do. If you encode a path with form encoding, the literal + stays in the URL and the spaces in the original become broken. Use standard encoding for paths.