Free URL Encoder & Decoder

Encode text for safe use in URLs or decode percent-encoded strings back to plain text. Handles spaces, &, ?, =, and all special characters.

Enter your details
Result
Enter your details on the left, then press Calculate.

Runs entirely in your browser. No text is sent to any server.

What is this calculator for?

You need to put a search query "best espresso machines under $500" into a URL parameter. Or you're debugging a broken link with strange %20 codes. The URL encoder converts characters that have special meaning in URLs (spaces, ampersands, quotes, slashes) to their percent-encoded equivalents (%20, %26, %22, %2F), and decodes them back. Essential for any web work with query strings, form submissions, or API calls.

URL encoding (also called percent-encoding) is defined in RFC 3986. The standard reserves certain characters for URL structure: / separates path segments, ? introduces query string, & separates parameters, = separates key from value, # introduces fragment. To include these characters in actual content (not as URL structure), they're percent-encoded: space → %20, & → %26, ? → %3F, / → %2F. Letters and digits aren't encoded; some symbols (-, _, .) are also safe.

This tool encodes plain text to URL-safe form and decodes URL-encoded text back. Use for: building URL parameters programmatically, debugging URLs with encoded characters, copying complex search URLs.

How to use this calculator

For encoding: paste text. The tool outputs URL-encoded version. "Hello World!" → "Hello%20World%21". "search query?" → "search%20query%3F".

For decoding: paste URL-encoded text. The tool outputs the original. "best%20espresso%20%24500" → "best espresso $500".

For full-URL encoding: some encoders encode just the path portion or just the query string; others encode the entire URL. For most uses: encode each parameter value separately, then assemble the URL. Don't encode the URL structure itself (the ?, &, = separating parts of the query string).

Understanding your results

The encoder outputs URL-safe text; the decoder outputs original text from percent-encoded input.

Common percent-encoded characters:

Space → %20 (or + in form-encoded variant).

! → %21. " → %22. # → %23. $ → %24. % → %25. & → %26. ' → %27. ( → %28. ) → %29. * → %2A. + → %2B. , → %2C. / → %2F. : → %3A. ; → %3B. < → %3C. = → %3D. > → %3E. ? → %3F. @ → %40.

Non-ASCII characters (é, 中, etc.) get encoded as UTF-8 multi-byte sequences. é → %C3%A9 (2 bytes UTF-8). 中 → %E4%B8%AD (3 bytes UTF-8). This makes URLs with non-Latin characters very long; some browsers display them in original form but transmit them percent-encoded.

The %20 vs + space confusion. Two ways to encode spaces in URLs. %20: the canonical RFC 3986 way; works in any URL part. +: a shortcut for spaces specifically in form-encoded query strings (Content-Type: application/x-www-form-urlencoded). So a search URL might be: ?q=best+espresso or ?q=best%20espresso — both work for most browsers, but they're technically different. In URL path components: use %20. In query string of form submissions: + is common but %20 also works.

URL length limits. RFC 3986 doesn't specify a maximum URL length. Browsers and servers impose limits: 2,083 chars (Internet Explorer historical), 8,192 chars (most modern browsers and servers), 16,000+ chars (some modern setups). For practical purposes, keep URLs under 2,000 characters; longer URLs may be truncated by some software or rejected by some servers. For very long data: POST request body instead of GET URL parameters.

Double-encoding bugs. Encoding an already-encoded URL produces garbled output. "%20" encoded again becomes "%2520" (% becomes %25, then 20 stays). Decoders that decode once won't recover the original. Always know whether your input is already encoded; encode only raw text, not already-encoded text.

A worked example

A developer is building a search feature that constructs URLs to Google. User searches for "best espresso machine under $500 & quiet".

Naive URL construction: https://google.com/search?q=best espresso machine under $500 & quiet — broken because the & introduces a new parameter (Google would see q=best espresso machine under $500 AND a separate empty parameter "quiet").

Correct construction with URL-encoded query value: https://google.com/search?q=best%20espresso%20machine%20under%20%24500%20%26%20quiet

Now the entire search string is one URL-encoded value of the q parameter. Google receives the literal search string with all characters intact.

JavaScript code: const url = 'https://google.com/search?q=' + encodeURIComponent(searchString). The encodeURIComponent() function handles all the encoding automatically. Use this for query parameter values; use encodeURI() for full URLs (doesn't encode ?, &, etc.).

Variation: she's debugging a broken URL in production. Browser address bar shows: https://example.com/search?q=jos%C3%A9. Decoding the q parameter: %C3%A9 is é (UTF-8 encoded). So the search was for "josé" — the URL is correct; it's just showing the Spanish accent properly encoded. Common confusion when developers see non-ASCII characters as percent-encoded; they're encoded, not broken.

Related resources

For other encoding/decoding tools, see Base64 and Hash Generator. For JSON in URLs (often requires URL-encoding the JSON), the JSON Formatter. For text manipulation, the Case Converter. The RFC 3986 is the authoritative IETF specification for URI generic syntax; WHATWG URL Standard covers modern browser URL handling.

Related calculators

base64hash generator

Frequently asked questions

Why do URLs need to be encoded?

URLs can only contain a limited set of ASCII characters. Spaces, &, ?, =, #, and most non-ASCII characters have special meaning in URLs or are not permitted. Percent-encoding converts these to % followed by their hexadecimal ASCII code (space becomes %20, & becomes %26), ensuring the URL is transmitted without ambiguity.

Which characters need encoding in URLs?

Unreserved characters that are always safe: A-Z, a-z, 0-9, -, _, ., ~ — never encode these. Reserved characters safe only in specific URL positions: : / ? # [ ] @ ! $ & ' ( ) * + , ; = — encode these when they appear in query parameter values. All other characters (spaces, accented letters, Chinese characters, emojis) must be encoded.

What is the difference between URL encoding and HTML encoding?

URL encoding (percent-encoding) converts characters to %XX format for use in URLs. HTML encoding (HTML entities) converts characters to &amp;, &lt;, &gt; etc. for use in HTML markup. They solve different problems: URL encoding prevents URL parsing ambiguity; HTML encoding prevents XSS and markup injection.

What characters need to be URL-encoded?

Reserved characters that have URL-structural meaning, plus characters that aren't in the 'unreserved set.' Reserved (need encoding when used as data): / ? # & = + : ; , @ $ ! ' ( ) * [ ]. Unreserved (safe to use as-is): A-Z a-z 0-9 - . _ ~. Everything else (spaces, %, <, >, etc.) should be encoded. Space is special — encoded as %20 in general URLs or + in form data. Practical rule: when in doubt, encode. Modern programming languages have functions (encodeURIComponent in JS, urllib.parse.quote in Python) that handle the rules automatically.

What's the difference between encodeURI and encodeURIComponent in JavaScript?

Scope of encoding. <code>encodeURI()</code>: encodes only characters not allowed in a URL. Leaves URL-structural characters alone (/, ?, &, =, etc.). Used when encoding an entire URL that may have already been assembled. <code>encodeURIComponent()</code>: encodes everything that's not a 'safe' character, including URL-structural ones. Used when encoding a single value that will be inserted into a URL (typical for query parameter values). For most use cases (constructing URLs with user input): use encodeURIComponent on each value, then assemble the URL with literal ? & = separators. Using encodeURI on full URLs is occasionally appropriate but less common.

Are URLs case-sensitive?

Mostly yes, with exceptions. Domain name: case-insensitive. EXAMPLE.COM and example.com point to the same server. Path: typically case-sensitive on Unix/Linux servers; case-insensitive on Windows servers. /Page and /page may or may not be the same depending on server. Query strings: case-sensitive in interpretation by the server application. Best practice: standardize on lowercase URLs for consistency. URL-encoded characters (%20, %26, etc.) are case-insensitive in the hex digits; %2F and %2f are equivalent.

How long can a URL be?

Browsers and servers impose limits, not the URL spec itself. Practical limits: Internet Explorer historical 2,083 chars (still relevant for legacy systems). Modern browsers: 32,000-64,000+ chars typically. Modern servers: 8,000-16,000 char URL limits typical (configurable). Google's robots.txt indexer: 2,083 chars (legacy). For SEO and shareability: keep URLs under 100 characters when possible — easier to copy, share, and remember. For data that doesn't fit in URLs: use POST requests with body data instead of GET parameters.

Why do some URLs have %20 and others have +?

Two encoding styles. RFC 3986 percent-encoding: spaces become %20 in any URL part. application/x-www-form-urlencoded: spaces become + in query strings of HTML form submissions (POST or GET). Both are valid for query strings; %20 is the more universal/safer choice. + is shorter but only works in query strings — if you put + in a path or fragment, it stays as literal + (not space). Most modern URL libraries default to %20 for safety. The + variant is a legacy from early web browsers and HTML forms; many systems still use it.