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.
It depends on where the result goes. Standard (encodeURIComponent) is right for a single query value, path segment, or fragment — the most common case. Strict encodes everything except the RFC 3986 unreserved set (A–Z a–z 0–9 - _ . ~), the safest choice when a downstream system is picky. Form encodes spaces as + for application/x-www-form-urlencoded bodies. Path-aware encodes a path but preserves the / separators so the structure survives.
%20 works everywhere in a URL and is the safe default — the Standard, Strict, and Path-aware variants all produce it. Use + (the Form variant) only when you’re building an application/x-www-form-urlencoded body, since that’s the one context where + is the expected space. Inside a URL path, + is a literal plus, so never use the Form variant for path segments.
Encode a single value with the Standard variant — it escapes /, ?, & and every other reserved character, which is exactly what you want for one query value or path segment. For a full path like /reports/2024 Q1/summary, use the Path-aware variant so the / separators are preserved while the spaces and special characters inside each segment are encoded. Never run a whole URL through Standard encoding — it would turn https:// into https%3A%2F%2F.
Tick “Encode each line separately.” Every line of input is encoded independently, so you can convert a whole column of values — say, a list of search terms or filenames — in one pass. Pair it with the Newline separator selector to control whether the output uses LF (Unix/web) or CRLF (Windows/MIME) line endings. Everything runs in your browser; nothing is uploaded.
It wraps the encoded output into 76-character lines, the convention used by MIME quoted-printable and similar email/transfer formats. Most web use doesn’t need it — a URL is a single unbroken string — but it’s useful when the encoded output is destined for an email header, a config file, or another system that expects wrapped lines. Leave it off for normal URL work.
No. The encoder runs entirely in your browser’s JavaScript. What you type, the encoded output, and everything in between stay in your browser tab — nothing is uploaded. Open DevTools → Network to verify no request carries your data, or disconnect from the internet and it still works. That makes it safe to encode values that contain tokens or other sensitive strings.
URL encoding — formally percent-encoding, defined in RFC 3986 — converts characters that aren’t safe in a URL into a % followed by their two-digit hexadecimal byte value. A space becomes %20, ? becomes %3F, and a non-ASCII character like é becomes its UTF-8 bytes %C3%A9. It lets special characters, spaces, and other alphabets travel safely inside a URL that only permits a limited ASCII set.
They solve different problems. URL encoding makes a string safe to travel inside a URL — a space becomes %20. HTML encoding makes a string safe to display inside a web page without being interpreted as markup — < becomes <, which helps prevent cross-site scripting. Use URL encoding for query values and paths; use HTML encoding when inserting user text into a page. They’re not interchangeable, and a value bound for both contexts needs each applied in the right place.
URL encoding escapes individual unsafe characters as %XX, keeping the text mostly readable — best for query values and paths. Base64 converts arbitrary binary data into a continuous stream of 64 safe characters — best for embedding files or binary payloads in text. One catch: standard Base64 output contains + and /, which still need URL-encoding unless you use the URL-safe “Base64URL” variant. For plain text in a URL, percent-encoding is the right tool.
No — encoding is a formatting change, not encryption. Anyone can reverse a percent-encoded string instantly, so it provides no confidentiality at all. Sensitive values like passwords or tokens should be sent in the body of an HTTPS POST request, never placed in a URL where they land in browser history, server logs, and referrer headers. Encode for transport safety, not secrecy.
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.
The encoder gives you four variants plus a few output controls. Here’s what each one produces and when to use it:
encodeURIComponent) — the default and the right choice most of the time. Encodes everything except letters, digits, and - _ . ! ~ * ' ( ), making it safe for a single query value, path segment, or fragment.A–Z a–z 0–9 - _ . ~. Use it when a downstream parser is strict about which characters may appear literally.+) — produces application/x-www-form-urlencoded output, where spaces become +. Use only for form bodies and query strings that expect that convention, never for path segments./) — encodes special characters inside each segment but keeps the / separators, so a full path stays structurally intact.Everything runs locally in your browser — no input is ever uploaded. To pick between encodeURIComponent and encodeURI in your own code, see the guide on encodeURI vs encodeURIComponent.
The output of this encoder follows the primary web standards that define percent-encoding. These are the specifications each encoding variant is built on:
%XX triplet the encoder produces; Section 2.3 defines the unreserved set (A–Z a–z 0–9 - _ . ~) that the Strict variant leaves untouched; Section 2.2 lists the reserved characters that must be encoded when they appear as data. The standard also recommends uppercase hex digits, which this tool emits. rfc-editor.org/rfc/rfc3986 §2.1application/x-www-form-urlencoded. Defines the Form variant, where a space becomes + and a literal plus is encoded as %2B. It’s a distinct convention from RFC 3986 and is what URLSearchParams and most HTML form submissions produce. url.spec.whatwg.orgé is encoded as its UTF-8 bytes (%C3%A9) rather than a single byte. rfc-editor.org/rfc/rfc3629Honest scope: the Standard variant matches JavaScript’s encodeURIComponent, which for historical reasons leaves ! ' ( ) * unencoded; the Strict variant encodes those too, for systems (OAuth signatures, some AWS APIs) that require full RFC 3986 compliance. Pick Strict when a downstream system rejects those characters.
Written and maintained by the urlencodedecode.com team. Every technical claim on this page is verified against primary sources — the RFCs (3986, 3629, 4648, 7578), the WHATWG URL Standard, and official vendor or language documentation — rather than second-hand summaries. When a source contradicts a common assumption, we follow the source and note the discrepancy. Corrections: contactus@urlencodedecode.com.