How URL Encoding Handles Spaces and Special Characters

URL encoding looks simple until a link breaks because of one character. A space, ampersand, question mark, slash, hash sign, or plus sign can change the meaning of a URL if it appears in the wrong place. That is why web applications encode unsafe or reserved characters before putting values into query strings, redirect URLs, API requests, analytics links, and form submissions.

This guide explains how URL encoding handles spaces and special characters, why different URL parts should be encoded differently, and how to avoid common mistakes when working with query parameters or nested URLs.

You can test the examples with the URL Encoder Decoder Online while reading.

What URL Encoding Does

URL encoding, also called percent-encoding, replaces characters with a % followed by two hexadecimal digits.

For example:

hello world

becomes:

hello%20world

The space is replaced with %20 because a raw space is not safe inside a URL.

URL encoding is not encryption. It does not hide data. It only makes text safe to place inside URL components.

Reserved Characters vs Unsafe Characters

Some characters are not merely unsafe. They already have structural meaning inside URLs.

Examples:

If one of these characters is part of a value, not part of the URL structure, it usually needs encoding.

For example, this query value is ambiguous:

https://example.com/search?q=design & tools

The raw ampersand can be interpreted as a parameter separator.

The safer version is:

https://example.com/search?q=design%20%26%20tools

Now the ampersand belongs to the value.

How Spaces Are Encoded

Spaces can appear as %20 or +, depending on the context.

In general URL percent-encoding, a space becomes:

%20

In application/x-www-form-urlencoded form encoding, a space is often represented as:

+

That difference causes confusion. For many modern URL-building workflows, %20 is the clearer and safer representation. If you are building query values with browser APIs such as URLSearchParams, the browser may use form-style encoding rules for the query string.

The practical advice:

• Do not manually replace spaces unless you know which encoding context you need.
• Use encodeURIComponent for individual query values.
• Use URL-building APIs when constructing full URLs programmatically.

Encode Values, Not Always the Whole URL

One of the most common URL encoding mistakes is encoding an entire URL when only a parameter value should be encoded.

Suppose you want this final URL:

https://example.com/search?q=red shoes

Only the value red shoes needs encoding:

https://example.com/search?q=red%20shoes

If you encode the whole URL, you get:

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dred%20shoes

That encoded version is no longer a normal clickable URL. It is useful only when the entire URL is being used as a value inside another URL.

Nested Redirect URLs

Nested URLs are where encoding becomes especially important.

Consider this redirect parameter:

https://auth.example.com/login?redirect=https://app.example.com/dashboard?tab=billing&plan=pro

This is risky because the inner URL contains ? and &, which can be interpreted as part of the outer URL.

The redirect value should be encoded:

https://auth.example.com/login?redirect=https%3A%2F%2Fapp.example.com%2Fdashboard%3Ftab%3Dbilling%26plan%3Dpro

Now the outer URL has one clear parameter: redirect.

Nested URLs appear in:

• OAuth flows.
• Login redirects.
• Password reset links.
• Campaign tracking links.
• Payment provider return URLs.
• Support or helpdesk deep links.

If a redirect stops at the wrong page, drops query parameters, or breaks after an ampersand, encoding is often the cause.

Ampersands in Query Values

Ampersands separate query parameters:

?source=google&medium=cpc

But sometimes an ampersand belongs inside the value:

research & development

As a query value, it should be encoded:

research%20%26%20development

Without encoding, the URL parser may treat development as a separate parameter or malformed segment.

This matters for UTM campaigns, search terms, product names, and user-generated filters.

If you are building campaign URLs, pair URL encoding with a dedicated UTM Builder so campaign fields stay readable and consistent.

Question Marks and Hash Signs

The first ? in a URL starts the query string:

https://example.com/page?query=value

The # starts a fragment:

https://example.com/page#section

If either character belongs inside a value, encode it.

Example value:

What is URL encoding?

Encoded:

What%20is%20URL%20encoding%3F

Example value:

chapter #2

Encoded:

chapter%20%232

If a raw # appears inside a query value, everything after it may be treated as the fragment and never reach the server.

Slashes in Values

A slash separates path segments:

/docs/api/reference

But a slash may also belong inside a parameter value, such as a category path, file path, or return URL.

Value:

docs/api/reference

Encoded as a query value:

docs%2Fapi%2Freference

Do not encode slashes that are meant to remain path separators. Do encode slashes when they are data inside a parameter value.

Plus Signs

The plus sign is tricky because form-style query decoding may treat + as a space.

If the literal value contains a plus sign:

C++ guide

the plus signs should be encoded:

C%2B%2B%20guide

Otherwise a decoder may interpret the value as:

C   guide

This is common in search terms, programming language names, grades, phone numbers, and encoded tokens.

Unicode Text

URL encoding also handles non-ASCII characters by encoding their UTF-8 bytes.

For example, a Unicode word or emoji becomes a sequence of percent-encoded bytes. You usually should not try to write those bytes manually.

Use browser APIs, a URL encoder, or server-side URL utilities so Unicode text is encoded consistently. This matters for internationalized search queries, names, tags, and product titles.

Encoding vs Escaping vs Base64

URL encoding is often confused with other transformations.

URL encoding makes text safe inside URL components.

HTML escaping makes text safe inside HTML.

JSON escaping makes strings safe inside JSON.

Base64 represents bytes as text.

These are not interchangeable. If you need to put a JSON string into a URL parameter, you may need more than one layer:

1. Create valid JSON.
2. Convert it to a string.
3. URL-encode that string as a query value.

If you are comparing encoding choices, see Base64 vs URL Encoding. If you are handling strings across multiple contexts, see the String Escaping Guide.

Practical Checklist

Use this checklist when a URL breaks:

• Is the broken character part of the URL structure or part of a value?
• Are query values encoded individually?
• Is a nested redirect URL encoded as a parameter value?
• Did a raw & split one value into multiple parameters?
• Did a raw # turn part of the value into a fragment?
• Are literal plus signs encoded as %2B?
• Are Unicode values encoded by a proper URL utility?
• Is the full URL encoded only when it is being nested inside another URL?

Bottom Line

URL encoding protects the structure of a URL by encoding values that contain spaces, special characters, reserved symbols, Unicode text, or nested URLs. The key is knowing what you are encoding: a query value, a path segment, a redirect URL, or a full URL used as data.

Use the URL Encoder Decoder Online when you need a quick browser-based way to encode or decode query values, redirect links, API parameters, and special characters without uploading your input.