Common URL Encoding Examples (Quick Reference)

Sometimes you do not need theory — you need to know what a particular character becomes when it is URL-encoded, and why. This guide is a practical reference of common URL encoding examples: the characters you meet most often, what they encode to, and the real-world situations where each one matters. Keep it handy and the percent codes in your URLs will stop being a mystery.

It is written for developers who build and debug URLs daily, students learning the mechanics, and anyone who wants a clear lookup of the encodings that come up most.

How to Read These Examples

Before the tables, a quick reminder of the rule behind every entry. URL encoding replaces a character with a percent sign followed by the two-digit hexadecimal value of its byte. Letters, digits and the four unreserved symbols (-, _, ., ~) never need encoding. Reserved characters — the ones with structural meaning in a URL — only need encoding when they appear as data rather than as delimiters. Everything else is encoded whenever it appears. With that in mind, the examples below show what each character becomes when it is being carried as data inside a URL.

In short: Common URL encodings include space as %20 (or + in forms), & as %26, ? as %3F, / as %2F, # as %23, = as %3D and + as %2B. Letters, digits and - _ . ~ are never encoded.

Understanding the Pattern Behind the Tables

Before reaching for a lookup table, it helps to understand that there is nothing to memorise in a deep sense — every encoding in this guide follows the same simple rule, and once you see it, the tables become a convenience rather than a necessity. The rule is that a character's percent-encoding is just a percent sign followed by the hexadecimal value of its byte. A space is byte number 32, and 32 in hexadecimal is 20, so a space encodes to %20. An ampersand is byte 38, which is 26 in hex, so it becomes %26. The percent sign itself is byte 37, which is 25 in hex, hence %25. The tables are simply a precomputed list of these byte-to-hex conversions for the characters you meet most often.

This is why you will sometimes see the same character written two ways and both being correct. Case in the hexadecimal does not matter — %2f and %2F both mean a slash — because hexadecimal digits are case-insensitive, though uppercase is the conventional and recommended form. And it is why a character you have never looked up before is still easy to encode: find its byte value and convert to hex, or simply let an encoder do it. The tables in this article cover the common cases, but the underlying pattern covers every case, which is the more valuable thing to carry away. A character is encoded by writing the hex of each of its bytes after percent signs, full stop.

Reserved Characters and Their Encodings

These characters carry structural meaning, so they must be encoded when used as data inside a value:

The two most consequential entries here are % and +. The percent sign must itself be encoded as %25, because it is the escape character — fail to do so and you risk double-decoding bugs. The plus sign must be encoded as %2B whenever you mean a literal plus, because in query strings a bare + is commonly decoded back into a space.

Other Common Symbols

Unicode and Non-English Characters

Characters beyond ASCII are first turned into UTF-8 bytes, and each byte is then percent-encoded, which is why a single accented or non-Latin character often produces several percent groups:

Notice how the byte count grows: a Latin-1 accented letter is two bytes, the euro sign and CJK characters are three, and emoji are four. The number of percent groups directly reflects how many UTF-8 bytes the character needs.

Real-World Examples

Seeing these encodings in context makes them stick. Here are a few everyday scenarios.

A search query. Searching for rock & roll produces a query string like ?q=rock%20%26%20roll (or ?q=rock+%26+roll in form style). The space and ampersand are encoded so the value is not misread as two parameters.

An email address in a URL. Passing jo+test@example.com as a value becomes jo%2Btest%40example.com. Note that both the + (to keep it from becoming a space) and the @ are encoded.

A redirect parameter. Embedding one URL inside another — ?next=/dashboard?tab=home — requires encoding the inner URL so its ? and / do not interfere: ?next=%2Fdashboard%3Ftab%3Dhome.

A path with a space. A file path segment like my report.pdf becomes my%20report.pdf so the space does not break the URL.

To produce or verify any of these instantly, paste the value into our URL Encoder/Decoder.

Producing These in Code

// JavaScript
encodeURIComponent("rock & roll");     // "rock%20%26%20roll"
encodeURIComponent("jo+test@x.com");   // "jo%2Btest%40x.com"
encodeURIComponent("€");               // "%E2%82%AC"

# Python
from urllib.parse import quote
quote("rock & roll")                    # "rock%20%26%20roll"
quote("jo+test@x.com")                  # "jo%2Btest%40x.com"

Try Our Free URL Encoder/Decoder

Rather than memorising hex codes, keep a converter open. Our URL Encoder/Decoder encodes and decodes any value instantly.

• ✅ Encode any text, including symbols and Unicode
• ✅ Decode percent-encoded values back to readable text
• ✅ Private and instant in your browser

👉 Encode or decode now →

Why These Particular Characters Cause Trouble

Not all of these characters are equally likely to bite you, and knowing which ones are the usual culprits helps you focus your attention. The space is the most common, simply because human input is full of spaces and they are outright forbidden in URLs, so any value carrying user text needs them handled. The ampersand is next, because it is the parameter separator — an unencoded ampersand inside a value silently splits one parameter into two, and the second half is often discarded by the server, producing a value that is mysteriously truncated. The slash causes trouble in path segments, where an unencoded one inside a value creates phantom segments and misroutes a request.

The two sneakiest characters are the percent sign and the plus sign. The percent sign is the escape character itself, so leaving it unencoded means the next two characters after it will be misinterpreted as a hex code — a value like "50% off" can decode into garbage if the percent is not turned into %25. The plus sign is sneaky in a different way: it looks harmless and is a valid URL character, but in query strings it is conventionally read as a space, so a literal plus in a phone number, a search for "C++", or an email like name+tag@example.com can silently become a space unless encoded as %2B. These two — percent and plus — account for a disproportionate share of real-world encoding bugs precisely because they fail quietly and only for certain inputs, so they are worth a second look whenever a value is not arriving as expected.

Reading Encoded URLs in the Wild

A practical skill that this reference builds toward is being able to glance at an encoded URL and understand what it actually contains, which is invaluable when debugging. When you see a query string like ?q=new%20york%20pizza&sort=price%2Casc, you can read straight through it: %20 is a space, so the query is "new york pizza," and %2C is a comma, so the sort value is "price,asc." A redirect parameter such as ?next=https%3A%2F%2Fexample.com%2Fhome decodes to "https://example.com/home" once you recognise %3A as a colon and %2F as a slash. With a little practice the common codes — %20, %2F, %3A, %3F, %3D, %26, %25, %2B — become as readable as the characters they stand for.

This fluency pays off most when something goes wrong. A URL that contains %2520 immediately tells you about double-encoding, because %25 is a percent sign and 20 follows it, meaning a %20 got encoded a second time. A value that looks like it has lost its pluses points to the plus-as-space convention. Seeing %C3%A9 tells you a UTF-8 multi-byte character (an accented letter) is present and being handled correctly. Rather than treating an encoded URL as opaque noise, you learn to read it as a slightly disguised version of plain text, which turns many debugging sessions into a quick visual scan. When the visual scan is not enough, pasting the URL into a decoder reveals the full plain-text version instantly.

Common Situations Where These Encodings Appear

Each of these encodings shows up in recognisable, recurring situations, and connecting the code to the scenario makes both easier to remember. The %20 space appears any time human-entered text rides in a URL — search boxes, file names, titles, addresses. The %40 at-sign and %2B plus appear constantly around email addresses, especially the "plus addressing" that services like Gmail support, where user+label@example.com must keep its plus intact. The %2F slash and %3A colon appear whenever one URL is embedded inside another, as in redirect, callback and return-to parameters, because the inner URL's own structure has to be neutralised so it does not interfere with the outer one.

The %23 hash matters whenever a value contains a literal hash that is not meant to start a fragment, such as a colour code or a social media tag passed as data. The %3F question mark and %3D equals sign come up when a value itself looks like it contains query syntax, which again is common with embedded URLs and with search filters expressed as text. And the multi-byte UTF-8 sequences appear the moment your application serves an international audience, where names, queries and content routinely include accented and non-Latin characters. Recognising these patterns means that when you see a particular code, you often already have a good guess about what kind of data it is carrying and why it needed encoding.

Common Mistakes

1. Forgetting to encode + as %2B. A literal plus in data otherwise becomes a space in query strings.
2. Not encoding the % sign itself. An unencoded percent confuses the decoder and causes double-decoding bugs.
3. Leaving reserved characters like & or / raw in a value, which breaks the URL structure.
4. Encoding non-ASCII with the wrong character set. Always use UTF-8 so the bytes decode correctly elsewhere.
5. Encoding the unreserved characters unnecessarily. It is harmless but produces uglier, longer URLs.

A Note on Consistency and Tooling

One theme runs through every example in this reference: consistency between the side that encodes and the side that decodes is what actually matters. An encoding is only useful if the receiver reverses it the same way, so the rare disagreements — chiefly the space-as-+ versus space-as-%20 convention — cause problems only when the two ends disagree. This is the strongest argument for using standard library functions and builders rather than hand-rolling encodings: well-established tools encode in the conventional way that decoders expect, so the round trip just works. When you produce percent codes by hand, you take on the burden of matching whatever convention the other side uses, and small mismatches produce exactly the silent, input-dependent bugs that are hardest to find.

For this reason, treat the tables in this article as a way to read and understand encoded URLs rather than as a manual you follow to produce them character by character. When you are building a URL, let a component encoder and a query-string builder generate the codes; when you are debugging one, use these tables (or a decoder) to interpret what you see. That division of labour — tools for producing, knowledge for reading — gives you both correctness and insight. You get encodings that are guaranteed to match what decoders expect, plus the ability to look at any encoded URL and understand precisely what it contains and why each code is there. That combination is what separates someone who is at the mercy of mysterious percent codes from someone who reads them as fluently as plain text and produces them without error.

Best Practices

• Encode each value with a component encoder rather than hand-writing percent codes.
• Remember the special cases: % → %25 and + → %2B.
• Use UTF-8 for all non-ASCII characters.
• Verify tricky values with a converter before shipping them in a link.
• Build query strings with a query API (like URLSearchParams) so encoding is handled for you.

Frequently Asked Questions

What does %20 mean in a URL?

%20 is the URL-encoded form of a space. Spaces are not allowed in URLs, so they are replaced with %20 (or, in form-encoded query strings, with a plus sign).

How is an ampersand encoded in a URL?

An ampersand used as data is encoded as %26, so it is not mistaken for the separator between query parameters.

Why must a plus sign be encoded as %2B?

In query strings a bare plus is commonly decoded back into a space, so a literal plus in your data must be encoded as %2B to survive intact.

How is an emoji or Chinese character URL-encoded?

It is converted to its UTF-8 bytes, and each byte is percent-encoded. An emoji is four bytes, for example 😀 becomes %F0%9F%98%80, and a CJK character like 中 is three bytes, %E4%B8%AD.

Which characters never need URL encoding?

The unreserved characters — letters A–Z and a–z, digits 0–9, and the symbols - _ . ~ — are always safe and never need encoding.

How do I encode the percent sign itself?

The percent sign is encoded as %25, because it is the escape character. Leaving it raw causes the decoder to misinterpret the following characters.

Summary

This reference captures the URL encodings you will meet most: spaces as %20, ampersands as %26, the structural punctuation like ?, /, #, = and : as their hex equivalents, the special cases of % as %25 and + as %2B, and Unicode characters expanded into their UTF-8 byte sequences. The single rule behind every entry is that a character becomes a percent sign plus the two-digit hex of each of its bytes, and that only data-bearing reserved characters and non-safe characters need it. Keep the tables close for quick lookups, lean on a component encoder and a query-string API in code, and use a converter to verify the tricky values — and building correct, unbreakable URLs becomes routine. The deeper reward is fluency: with these encodings familiar, an encoded URL stops being an intimidating wall of percent signs and reads instead like the plain text it represents, which makes both building links and debugging them noticeably faster.

👉 Look up any encoding with our free tool →

Related Resources

• What Is URL Encoding? — the fundamentals
• How to Encode Special Characters in URLs — the practical guide
• URL Encoding vs HTML Encoding — two contexts
• URL Encoder/Decoder — the tool