URL Encoding and Decoding Explained (With Free Online Tool)

You have seen URL encoding without thinking about it: the %20 where a space used to be, the %C3%A9 standing in for an é, the long string of percent signs at the end of a Google search URL. Every time text travels through a URL — a search query, a redirect, a tracking parameter — URL encoding makes sure it arrives intact.

This guide explains what URL encoding is, how it works, when each variant applies, and how to encode or decode any string instantly online.

What is URL encoding?

URL encoding (also called percent encoding) is a way to represent characters that are not safe to use directly in a URL. The encoded form of a character is a percent sign followed by two hexadecimal digits — for example, a space becomes %20, an ampersand becomes %26, and a forward slash becomes %2F.

The reason it exists: URLs have structure. Specific characters carry specific meaning — ? separates the path from the query string, & separates query parameters, # introduces a fragment. If those characters appear inside a value rather than as structural delimiters, they need to be disguised so browsers and servers do not misinterpret them.

To encode or decode a URL without installing anything, use the FixTools URL Encoder and URL Decoder.

How URL encoding works

The rules come from RFC 3986, the specification for URIs. Every character is classified as either safe (allowed without encoding), reserved (allowed only as a structural delimiter), or unsafe (must be encoded).

Unreserved characters (never encoded)

These pass through unchanged:

• Letters: A–Z, a–z
• Digits: 0–9
• Four punctuation marks: -, _, ., ~

Anything in this set is always safe in any part of a URL.

Reserved characters (encoded only when used as data)

These have structural meaning. They are allowed when used as delimiters and must be encoded when they appear inside a value:

: / ? # [ ] @ ! $ & ' ( ) * + , ; =

The slash separating two path segments stays a slash. A slash that is part of a query parameter value — for example, the value 2026/04/30 — must be encoded as 2026%2F04%2F30. Otherwise the URL parser would treat it as a path boundary.

Everything else (always encoded)

Anything outside the unreserved and reserved sets must be percent encoded. This includes:

• Spaces and tabs
• Control characters
• Non-ASCII characters (accented letters, emoji, Chinese, Arabic, and so on)

Non-ASCII characters are first converted to UTF-8 bytes, and then each byte is percent encoded. The character é is two UTF-8 bytes (0xC3 0xA9), so it encodes to %C3%A9. The character 中 is three UTF-8 bytes (0xE4 0xB8 0xAD), so it encodes to %E4%B8%AD.

A worked example

Take the search query: tea & coffee — café (15% off)

To put this in a URL parameter, every problematic character has to be encoded:

Character	Encoded
space	%20
&	%26
— (em dash, UTF-8: 0xE2 0x80 0x94)	%E2%80%94
é (UTF-8: 0xC3 0xA9)	%C3%A9
(	%28
)	%29
%	%25

The encoded string is:

tea%20%26%20coffee%20%E2%80%94%20caf%C3%A9%20%2815%25%20off%29

Once placed in a URL: https://example.com/search?q=tea%20%26%20coffee%20%E2%80%94%20caf%C3%A9%20%2815%25%20off%29

When the server receives it, it decodes each %XX back to the original byte and reassembles the original string. Both ends end up with identical text.

The two flavors of URL encoding

There are two slightly different conventions, and mixing them is one of the most common sources of bugs.

Standard percent encoding (RFC 3986)

Used for path components and any URL segment outside of form data. Spaces become %20. Everything follows the rules described above.

Form encoding (`application/x-www-form-urlencoded`)

Used when a browser submits an HTML form via GET, and historically extended to query strings in general. The differences from standard percent encoding:

• A space is encoded as + (instead of %20)
• A literal + must be encoded as %2B (so it is not mistaken for a space)
• A few characters that are reserved in RFC 3986 but rarely cause structural issues (such as /) are sometimes left unencoded

This is why you can paste a search URL containing + into a browser bar and the result still works — the browser knows the query string uses form encoding and reads + as a space.

The decoder you use must match the encoding flavor. A standard percent decoder will leave + alone; a form decoder will turn + into a space. The FixTools URL Decoder handles both: paste the string and it will produce the correct decoded text whether it came from a path or a form-encoded query.

When you need URL encoding

Search queries and dynamic links

Any time user input is placed in a URL — a search box, a category filter, a share link — the input has to be encoded. Without encoding, an ampersand in the user's text would split the query string into two parameters, and a hash sign would truncate everything after it.

Redirects

Redirect URLs frequently include the original URL as a query parameter so the user can be sent back after login or checkout: ?next=https://example.com/cart. The next value contains a colon, slashes, and possibly a query string of its own, so it has to be encoded. A failure to encode here is the most common cause of broken redirects after authentication.

REST API path parameters

When a resource identifier contains a slash, space, or unicode character, it has to be encoded so the server's router does not split it across path segments. For example, a document title used as a path identifier — /docs/Q3 2026 plan — must become /docs/Q3%202026%20plan.

Tracking parameters and analytics

Campaign URLs (UTM parameters, click IDs, referrer values) often contain spaces, ampersands, and accented characters. Without encoding, the analytics tool receives mangled data — or worse, the URL silently breaks for some users and works for others depending on how their browser handles the malformed input.

Email and chat links

mailto: links, prefilled SMS links, and WhatsApp share links all use URL encoding for the message body. A newline becomes %0A, a space becomes %20, and the entire body has to be a single encoded string in the URL.

URL encoding in code

Most languages provide built-in functions for both standard and form-style URL encoding.

JavaScript:

const value = 'tea & coffee';
encodeURIComponent(value);
// Returns: 'tea%20%26%20coffee'

decodeURIComponent('tea%20%26%20coffee');
// Returns: 'tea & coffee'

Use encodeURIComponent for individual values (a parameter, a path segment) and encodeURI for whole URLs that should preserve their structure (encodeURI will not encode : or /).

Python:

from urllib.parse import quote, unquote, quote_plus
quote('tea & coffee')          # 'tea%20%26%20coffee' (path-safe)
quote_plus('tea & coffee')     # 'tea+%26+coffee' (form-safe)
unquote('tea%20%26%20coffee')  # 'tea & coffee'

quote produces standard percent encoding (space → %20); quote_plus produces form encoding (space → +).

PHP:

rawurlencode('tea & coffee');  // 'tea%20%26%20coffee'
urlencode('tea & coffee');     // 'tea+%26+coffee'
rawurldecode($encoded);

rawurlencode matches RFC 3986; urlencode matches form encoding.

Common mistakes

Double encoding

A value that has already been encoded gets encoded a second time. The space %20 becomes %2520 (because the % itself gets encoded as %25). When decoded once, the result is %20 instead of a space. Encode exactly once, at the boundary where data enters the URL. If a value arrives already encoded, do not encode it again.

Encoding a whole URL with `encodeURIComponent`

encodeURIComponent('https://example.com/path') produces https%3A%2F%2Fexample.com%2Fpath — a single string with no usable structure. Use encodeURI for whole URLs and encodeURIComponent for the parts you are placing inside a URL.

Mixing form encoding and percent encoding

A URL built with + for spaces in the path will fail because path components do not use form encoding. A query string built with %20 for spaces is technically valid but will be returned as %20 (not +) when read back through a form decoder. Pick the right tool for each part of the URL: standard percent encoding for the path, form encoding for query string values built from form data.

Forgetting that decoding can fail

A user-supplied URL parameter may contain an incomplete percent escape — a stray % not followed by two hex digits — which makes the entire string invalid. Code that decodes URL parameters should handle this case rather than crashing.

Encode or decode a URL now

Use the FixTools URL Encoder to convert any text into a URL-safe percent-encoded string, ready to drop into a query parameter, redirect target, or mailto: body. Use the URL Decoder to read back the original text from any encoded URL — useful for debugging tracking parameters, decoding logged URLs, or reading a redirect chain. Both tools work entirely in your browser and handle UTF-8 multi-byte characters automatically.