URL Encode / Decode Online Free — Percent-Encoding Explained [2026]

What is URL percent-encoding and why it exists

A URL can only contain a limited set of characters from the ASCII character set. Characters outside that set, or characters that carry special meaning in a URL — like spaces, slashes, ampersands, and question marks — cannot appear in their raw form inside certain URL components. When they do, the URL becomes ambiguous or invalid.

Percent-encoding, formally defined in RFC 3986, solves this by substituting each problematic character with a percent sign followed by two hexadecimal digits representing the character's UTF-8 byte value. A space is encoded as %20 because 20 is the hexadecimal representation of 32, the ASCII code for space. A forward slash becomes %2F, an ampersand becomes %26, and a hash becomes %23.

You encounter percent-encoding every day without noticing it. When you search for something on Google and look at the address bar, you see your query transformed: spaces become + or %20, special characters become percent sequences. When you click a link in an email with tracking parameters, those parameters are percent-encoded. When a REST API receives a query with a user-submitted value, that value must be encoded to prevent the parser from misinterpreting it.

The encoding is reversible: a percent-encoded string can always be decoded back to its original form. The decoding process replaces each %XX sequence with the character whose UTF-8 byte value is XX in hexadecimal.

Reserved vs unreserved characters: the full table

RFC 3986 divides URL characters into two groups. Unreserved characters are safe to use in any URL component without encoding. Reserved characters have structural meaning and must be encoded when they appear as data rather than as URL delimiters.

A practical way to remember the rule: if you are embedding a user-supplied value or any arbitrary string inside a URL, encode every character except letters, digits, hyphen, underscore, period, and tilde. When in doubt, encode more rather than less — a correctly encoded URL always works, but an under-encoded one may silently misbehave.

encodeURIComponent vs encodeURI: when to use each

JavaScript provides two built-in functions for URL encoding, and choosing the wrong one is one of the most common bugs in web development. The difference comes down to what they are designed to encode.

encodeURIComponent is designed to encode a single component value — a query parameter value, a path segment, or any piece of data that will be embedded inside a URL. It encodes all characters except: A-Z a-z 0-9 - _ . ! ~ * ' ( ). This means it encodes / ? # & = : @ — all the structural URL characters. That is exactly what you want when encoding a value, because those characters must not be interpreted as URL structure.

encodeURI is designed to encode a complete URL while preserving its structure. It leaves unencoded all the characters that have structural roles in URLs: ; , / ? : @ & = + $ # in addition to the unreserved characters. This makes it useful only when you have a full URL and want to encode non-ASCII characters or spaces without breaking its structure. You should never use encodeURI on a parameter value that could contain & or = — those characters will pass through unencoded and corrupt the query string.

The practical rule: always use encodeURIComponent for parameter values. Use encodeURI only in the rare case where you have a complete URL (perhaps received from user input) and want to make it URL-safe without destroying its structure. In most codebases, encodeURIComponent is the right choice 95% of the time.

%20 vs +: which to use for spaces

Both %20 and + can represent a space in a URL, but they belong to different encoding standards and are not interchangeable in all contexts.

%20 is the RFC 3986 standard encoding for a space. It is produced by encodeURIComponent and is valid in every URL component — path segments, query strings, fragment identifiers. It is universally understood by every HTTP library, server, and language runtime.

+ as a space representation comes from the application/x-www-form-urlencoded MIME type — the format browsers use when submitting HTML forms via GET or POST. In that context only, a + in the query string is decoded as a space. This convention predates RFC 3986. Outside of HTML form submissions, a + is a literal plus sign, not a space.

The safest rule: always use %20 (produced by encodeURIComponent) unless you are explicitly building application/x-www-form-urlencoded data for an HTML form. APIs that expect RFC 3986-compliant URLs will interpret a + literally and your search query "hello world" will arrive as "hello+world" instead.

Common characters and their percent-encoded values

The table below covers the characters most frequently encountered when building URLs manually, constructing API requests, or debugging broken query strings. The "Encoded form" column shows the result of applying encodeURIComponent.

Double encoding: the most common mistake

Double encoding happens when a string that is already percent-encoded gets encoded again. The most visible symptom: a literal %25 appearing in your URL where you expect %20 or another encoded character.

Here is what happens step by step. Suppose a user submits the string hello world. You encode it once: hello%20world. Now if you pass that result to encodeURIComponent again — or if a framework automatically encodes what you already encoded — the % in %20 becomes %25, turning your encoded space into hello%2520world. The server receives hello%20world as a literal string — a different value from the user's original input.

Common sources of double encoding in real codebases:

• Manually encoding a value before passing it to a library that also encodes it internally. Axios, fetch, and most HTTP clients encode URL parameters automatically when you pass them as objects. If you pre-encode, they double-encode.
• Receiving an already-encoded URL and passing it as a parameter value. If you receive a callback URL like https://app.com/auth?token=abc and encode it as a redirect parameter, the URL is encoded. If you then pass that parameter value through encodeURIComponent again, it double-encodes.
• String concatenation across multiple layers. A value is encoded at the API layer, passed to a router, which encodes the URL again, which passes it to a redirect handler that encodes it one more time.

The fix is simple: encode each raw value exactly once, as late as possible in the URL construction process. If a value arrives already encoded (from an external source), decode it first with decodeURIComponent, then re-encode it as needed for your specific context. Never assume the encoding state of a string received from outside your system.

Encoding URL parameters for API requests

API requests are where percent-encoding mistakes are most costly. A missing or incorrect encoding can produce a 400 Bad Request, return wrong data silently, or — in the worst case — expose a security vulnerability (open redirect, parameter injection). Here are the patterns that come up most often.

Building a search query with spaces and special characters. A user searches for "coffee & donuts". The raw string contains a space and an ampersand. You need to pass it as the q parameter. Correct approach:

const query = "coffee & donuts";
const url = "https://api.example.com/search?q=" + encodeURIComponent(query);
// Result: https://api.example.com/search?q=coffee%20%26%20donuts

Passing a redirect URL as a parameter. You want to redirect the user back to a URL after authentication. The redirect URL itself contains slashes, question marks, and more parameters. It must be fully encoded as a single parameter value:

const redirectUrl = "https://app.com/dashboard?tab=settings&mode=edit";
const loginUrl = "https://auth.example.com/login?redirect=" + encodeURIComponent(redirectUrl);
// Result: https://auth.example.com/login?redirect=https%3A%2F%2Fapp.com%2Fdashboard%3Ftab%3Dsettings%26mode%3Dedit

Multiple parameters constructed safely. Use URLSearchParams in JavaScript — it handles encoding automatically and correctly for each value:

const params = new URLSearchParams({
  q: "coffee & donuts",
  lang: "en",
  page: "1",
});
const url = "https://api.example.com/search?" + params.toString();
// Result: https://api.example.com/search?q=coffee+%26+donuts&lang=en&page=1
// Note: URLSearchParams uses + for spaces (form encoding), not %20.
// For strict RFC 3986, use encodeURIComponent manually.

Note that URLSearchParams uses the application/x-www-form-urlencoded format, encoding spaces as + rather than %20. Most API servers accept both, but if your target API requires strict RFC 3986 encoding, build the query string manually with encodeURIComponent.

How to encode or decode a URL online, step by step

1. Open the URL Encode / Decode tool. Go to omnikitbolt.com/tools/url-encode-decode in any modern browser. No signup, no extension required.
2. Paste your string. Paste the URL, parameter value, or percent-encoded string into the input field. For encoding: paste the raw string with spaces and special characters. For decoding: paste the percent-encoded string (e.g. coffee%20%26%20donuts).
3. Click Encode or Decode. Encode converts the raw string to its percent-encoded form using encodeURIComponent. Decode converts the percent-encoded form back to its original text using decodeURIComponent.
4. Copy the result. Click the copy button. The output is ready to paste into your API call, code, terminal command, or browser address bar.
5. Verify if needed. If you received a percent-encoded string and want to confirm its decoded value, paste the encoded form and click Decode. The result is what a server or application would receive after decoding.

The tool runs entirely in your browser using JavaScript's native encodeURIComponent and decodeURIComponent functions. No data is transmitted to any server. Sensitive strings — API keys embedded in URLs, OAuth tokens, internal endpoint paths — stay on your device.

Related tools

• URL Encode / Decode: the tool covered in this article. Encode or decode any URL or parameter value using native encodeURIComponent / decodeURIComponent. No upload, no server. See also: step-by-step encode / decode guide.
• Hash Generator: generate MD5, SHA-1, SHA-256, SHA-384, or SHA-512 hashes from text or files in your browser. Useful for verifying file integrity or creating checksums. See hash generator guide.
• QR Code Generator: generate QR codes from any URL, text, Wi-Fi credentials, email, or vCard. No signup, no expiry. Download PNG or SVG. See QR code generator guide.
• Image to Base64: encode any image to Base64 for embedding in HTML, CSS, or API payloads. No upload, no server. See Image to Base64 guide.