URL Encoding Explained: When to Encode, Decode, and Why It Matters
Understand with AI
Discuss with your preferred AI assistant
RFC 3986 reserves 18 characters that must be percent-encoded when used as data inside a URL.
%20 works in both the path and the query string; + only works in form-style query strings.
Zero network calls — encoding and decoding happen entirely in your browser, so nothing is uploaded.
URL encoding is the quiet plumbing of the web. Every time you paste a link with a space in it, share a search results page, or build a tracking URL, encoding decides whether that link works or breaks. Get it right and your campaigns track cleanly and your pages stay crawlable; get it wrong and you lose UTM data, trigger 404s, or hand search engines a broken canonical.
This guide explains what URL encoding is, why it exists, and exactly when to use component versus full-URL escaping — so you can encode and decode with confidence instead of guessing.
What Is URL Encoding?
URL encoding — also called percent-encoding — replaces characters that are unsafe or reserved in a URL with a percent sign followed by two hexadecimal digits. A space becomes %20, an ampersand becomes %26, and a question mark becomes %3F. The rules come from RFC 3986, the specification that defines what a valid URL looks like.
The reason is simple: URLs can only safely contain a limited set of characters. Letters, digits, and a handful of marks like hyphen, underscore, period, and tilde are allowed as-is. Everything else — spaces, accented letters, emoji, and characters that have special meaning like ?, &, =, /, and # — must be encoded so the browser and server agree on where one part of the URL ends and the next begins.
Why URL Encoding Matters for SEO and Marketing
Encoding is not just a developer concern. It directly affects how your links behave in the wild:
- Campaign tracking: If a UTM value contains an unencoded ampersand or space, analytics platforms split or truncate it — and your attribution data is silently wrong.
- Crawlability: Search engines treat %20 and a raw space differently. Inconsistent encoding can create duplicate URLs that split ranking signals.
- Sharing: A link with raw spaces often breaks when pasted into email, chat, or social platforms, which cut it off at the first space.
- Internationalization: Non-ASCII characters in slugs (café, naïve, 日本語) must be percent-encoded to travel reliably across systems.
Component vs. Full-URL Encoding
This is the single most important decision when encoding, and the source of most mistakes. There are two scopes, and they exist for different jobs.
Component encoding (encodeURIComponent)
Use this when you are encoding one piece of a URL — a single query-string value, a path segment, or a slug. It escapes everything reserved, including ?, &, =, /, and #. That is exactly what you want for a value, because those characters would otherwise be misread as URL structure. For example, the value seo tools & analytics becomes seo%20tools%20%26%20analytics, so the ampersand can't be mistaken for a parameter separator.
Full-URL encoding (encodeURI)
Use this when you have a complete URL and only want to escape the genuinely illegal characters (like spaces) while keeping the structural characters intact. It deliberately does not escape : / ? & = #, because those need to stay literal for the link to keep working. Encoding an entire URL with component encoding is a classic bug — it mangles the https:// into https%3A%2F%2F and the link dies.
Rule of thumb: encoding a value? Use component. Cleaning up a whole link? Use full-URL.
%20 vs. + for Spaces
You will see spaces encoded two ways. In the path of a URL, a space is always %20. In a query string submitted by an HTML form, a space is often encoded as + — the application/x-www-form-urlencoded convention. Both are valid in the query, and most servers accept either, but they are not interchangeable everywhere: a literal + in a path means a plus sign, not a space. When in doubt, %20 is the universally safe choice; use + only when you are specifically building form-style query strings.
How to Use This URL Encoder / Decoder
- Paste your URL or text on the left. Switch between Encode and Decode with one click.
- Pick the scope — Component for a single value, or Full URL for an entire link.
- Toggle %20 vs + when you need form-style query encoding.
- Read the breakdown — the tool parses your URL into protocol, host, path, query, and fragment, and lists each query parameter decoded so you can spot a mistake instantly.
- Copy or download the result. Everything runs locally in your browser — nothing is sent to a server.
Common URL Encoding Mistakes
- Encoding a whole URL with component encoding, which destroys https:// and the slashes.
- Double-encoding — running an already-encoded string through encode again, turning %20 into %2520.
- Forgetting to encode an ampersand inside a value, which silently truncates the parameter.
- Mixing + and %20 inconsistently, so some systems read a literal plus sign.
Expert Tips
Encode the value, not the whole URL
When you only need to escape one query parameter or slug, use component encoding so reserved characters like & and = are escaped. Reserve full-URL encoding for entire links so https:// and the slashes survive.
Watch for double-encoding
If you see %2520 or %253F in a link, it was encoded twice — %20 became %2520. Decode once to confirm, then re-encode the original raw text exactly one time.
Frequently Asked Questions
What is the difference between encodeURI and encodeURIComponent?
encodeURI escapes only characters that are illegal in a full URL and keeps structural characters like : / ? & = # intact, so it is for encoding an entire link. encodeURIComponent escapes every reserved character, so it is for encoding a single value such as one query-string parameter or path segment.
When should I use %20 instead of + for spaces?
Use %20 anywhere — it is valid in both the path and the query string and is the universally safe choice. Use + only for form-style (application/x-www-form-urlencoded) query strings, and never in the path, where + means a literal plus sign rather than a space.
Why does my decoded URL look wrong or throw an error?
Decoding fails when the input contains a malformed percent-escape — a stray % not followed by two valid hex digits, or a sequence like %ZZ. It can also look wrong if the string was double-encoded; in that case decode it twice. Check for an orphaned % sign first.
Is it safe to encode passwords or tokens in a URL?
You can safely percent-encode a token so it survives transport, but putting secrets in a URL is risky because URLs get logged in server logs, browser history, and analytics. Encode them with component scope if you must, but prefer headers or request bodies for anything sensitive.