URL Encode / Decode
Enter the text that you wish to encode or decode:
About URL Encode / Decode
You are building an API call. The endpoint accepts a search query as a URL parameter. The query contains a space, an ampersand, and a hashtag. You send the request and nothing works — the server interprets the ampersand as a parameter separator, the hashtag as a fragment identifier, and your query breaks into three unrecognisable pieces. This is the problem URL encoding solves. It has solved it since 1994. And if you have never formally learned how it works, you are likely running into its consequences more often than you realise.
The DigitalSub Pro URL Encoder / Decoder converts any text or URL instantly — either encoding special characters into their safe percent-encoded equivalents, or decoding a percent-encoded string back to its readable form. Paste your string, select encode or decode, and the result is ready to copy in under a second. No limits, no account, no setup.
This page covers both how to use the tool and everything worth understanding about URL encoding — from the exact algorithm that converts a space to %20, to why the same space becomes + in some contexts, to the specific bugs that double-encoding creates, to the right encoding function to use in each programming language. All of it in plain language, with real examples.
3986
- Live Encoding & Decoding Examples
- What URL Encoding Is — and Why It Exists
- How the Encoding Algorithm Works Step by Step
- Which Characters Need Encoding — and Which Never Do
- The Space Problem: %20 vs + — a Critical Distinction
- How Unicode and Non-ASCII Characters Are Handled
- The 4 Most Common URL Encoding Mistakes
- Real-World Use Cases
- How to Use the Tool
- Encoding in Different Programming Languages
- Pro Tips
- Related Tools
- Frequently Asked Questions
Live Encoding & Decoding Examples
Before the theory, here is what the tool actually does — three real encoding examples so you can see immediately how it transforms different types of input.
What URL Encoding Is — and Why It Exists
URLs can only contain a specific subset of ASCII characters. Letters (A–Z, a–z), digits (0–9), and a handful of special characters like hyphens, underscores, and tildes are safe. Everything else — spaces, ampersands, equals signs, hashtags, non-English letters, emoji, Chinese characters — is not natively allowed in a URL and must be converted into a format that is safe to transmit over the internet.
That conversion is URL encoding, officially named percent-encoding in RFC 3986 (the IETF standard for Uniform Resource Identifiers, published in 2005 by Tim Berners-Lee and colleagues). The mechanism is simple: replace each unsafe character with a percent sign (%) followed by two hexadecimal digits that represent the character's ASCII or UTF-8 byte value. A space (ASCII decimal 32, hex 20) becomes %20. An ampersand (ASCII 38, hex 26) becomes %26. An equals sign (ASCII 61, hex 3D) becomes %3D.
URL encoding exists because the internet's communication protocols are built on ASCII text. HTTP — the protocol that moves web pages, API requests, and data around the internet — was designed in an era when English text and a narrow set of symbols covered almost all use cases. As the web became global, the need to transmit URLs containing spaces, accented characters, Chinese text, Arabic script, and thousands of other Unicode characters became unavoidable. Percent-encoding is the bridge that lets non-ASCII data travel safely inside a URL structure designed for ASCII.
How the Encoding Algorithm Works — Step by Step
The mechanics of percent-encoding are straightforward once you see them laid out. Every character in your input goes through the same decision process, and the result is always deterministic — the same character always produces the same encoded output.
Letters (A–Z, a–z), digits (0–9), and four special characters — hyphen (-), underscore (_), period (.), and tilde (~) — are unreserved. They are safe in any part of a URL without modification. Leave them exactly as they are.
Every character in standard ASCII has a decimal value from 0 to 127. A space is decimal 32. An ampersand is decimal 38. An at sign is decimal 64. The hashtag is decimal 35. These values are defined in the ASCII standard and are fixed — they never change.
space = 32 & = 38 @ = 64 # = 35 = = 61Hexadecimal is a base-16 number system using digits 0–9 and letters A–F. Decimal 32 becomes hex 20. Decimal 38 becomes hex 26. Decimal 64 becomes hex 40. Decimal 35 becomes hex 23. This is the core mathematical operation in percent-encoding — and why the resulting codes always look like two-character sequences of digits and letters.
32 → 20 38 → 26 64 → 40 35 → 23 61 → 3DThe final encoded character is a literal % symbol followed by the two-digit hex value. This is why the system is called percent-encoding. A space (hex 20) becomes %20. An ampersand (hex 26) becomes %26. An at sign (hex 40) becomes %40. A hashtag (hex 23) becomes %23.
Characters outside basic ASCII (accented letters like é, Chinese characters, Arabic script, emoji) are first converted to their UTF-8 byte sequence, then each byte is percent-encoded individually. The letter é is two UTF-8 bytes (hex C3 A9), so it encodes to %C3%A9. A Chinese character like 你 is three UTF-8 bytes (E4 BD A0), encoding to %E4%BD%A0. This is why encoded non-ASCII characters produce long sequences of percent codes.
Which Characters Need Encoding — and Which Never Do
RFC 3986 divides all characters into three categories. Knowing which category a character falls into tells you immediately whether it needs encoding — and if so, what it encodes to.
| Character(s) | Category | Encoded Form | Notes |
|---|---|---|---|
| A–Z, a–z, 0–9 | Unreserved — never encode | No change | Always safe in any URL position |
| - _ . ~ | Unreserved — never encode | No change | Safe in paths, queries, fragments |
| space | Must encode as data | %20 | Or + in form-encoded query strings (see section below) |
| / ? # [ ] @ | Reserved — context-dependent | %2F %3F %23 %5B %5D %40 | Safe as URL structure delimiters; must encode when used as data values |
| ! $ & ' ( ) * + , ; = | Reserved — context-dependent | %21 %24 %26 %27 %28 %29 %2A %2B %2C %3B %3D | Used in URL structure; encode when appearing inside a parameter value |
| @ | Must encode in most values | %40 | Email addresses in URL params: user%40example.com |
| % | Must encode when literal | %25 | A literal percent sign — not used as encoding prefix |
| é ü ñ (Latin extended) | Must encode — non-ASCII | %C3%A9 %C3%BC %C3%B1 | UTF-8 bytes, each percent-encoded individually |
| 你好 (Chinese) | Must encode — non-ASCII | %E4%BD%A0%E5%A5%BD | Three UTF-8 bytes per character |
| ? (Emoji) | Must encode — non-ASCII | %F0%9F%94%8D | Four UTF-8 bytes for most emoji |
The Space Problem: %20 vs + — a Critical Distinction
If you have ever looked at URLs from different web applications and noticed that some spaces appear as %20 while others appear as +, you were not seeing an error — you were seeing two different, legitimate encoding flavours that exist for historical reasons and apply in different contexts. Confusing them causes bugs that can be surprisingly hard to trace.
%20
The formally correct encoding for a space in any part of a URL, as defined by RFC 3986. Works correctly in URL paths, query strings, and all URL components across all systems. This is what the DigitalSub Pro URL Encoder produces, and what you should use in any modern context.
q=coffee%20cake — always unambiguous
+
A legacy convention from HTML form submissions where a space in a form field value gets encoded as +. This comes from the older application/x-www-form-urlencoded MIME type used when browsers submit HTML forms. It only applies in query strings — a + in a URL path is treated as a literal plus sign, not a space.
q=coffee+cake — works in forms, ambiguous elsewhere
Searching for "C++ programming" using form encoding
A search box uses form encoding and the user types C++ programming. The form encodes it and sends:
q=C%2B%2B+programmingThe server decodes the + as a space (form encoding rule) and receives: C++ programming — correct.
But if a developer copy-pastes that URL into a system that uses strict RFC 3986 percent-decoding rather than form-decoding, the + is NOT decoded as a space — it is treated as a literal plus sign. The server receives: C++programming — the space is gone, the query is wrong.
Rule: Use %20 for spaces in any context you control. Use + only when you know you are explicitly working with HTML form submission encoding.
How Unicode and Non-ASCII Characters Are Handled
The original URL specification was designed for ASCII characters only. As the web expanded globally, this became a serious limitation — URLs in Arabic, Chinese, Japanese, Korean, Hindi, and dozens of other scripts needed to work reliably. The solution, standardised in RFC 3987 for Internationalized Resource Identifiers (IRIs) and implemented through UTF-8 encoding, is the mechanism that makes global URLs work today.
The UTF-8 Encoding Process for Non-ASCII Characters
When a character outside basic ASCII appears in a URL, it is first converted to its UTF-8 byte sequence, then each individual byte is percent-encoded separately. UTF-8 is a variable-width encoding that represents Unicode characters as 1 to 4 bytes depending on the character's value. Basic ASCII characters map to a single byte; most Latin-extended characters use 2 bytes; Chinese, Japanese, and Korean characters typically use 3 bytes; emoji and rare scripts use 4 bytes.
This is why modern browsers display a URL like https://example.com/café in the address bar in readable form, even though the actual HTTP request transmits https://example.com/caf%C3%A9. The browser automatically encodes for transmission and decodes for display — making the web feel seamless even though the underlying mechanism is doing UTF-8 byte encoding behind the scenes.
The 4 Most Common URL Encoding Mistakes
URL encoding mistakes are among the hardest bugs to diagnose in web development — because the symptom (broken request, missing data, 400 error) is often far removed from the cause (wrong encoding at the source). Here are the four mistakes that account for the vast majority of encoding-related issues.
Double Encoding
Encoding an already-encoded string again. The first encoding turns a space into %20. The second encoding sees the % and encodes it to %25, turning %20 into %2520. The server receives the literal string "%20" rather than a space. This breaks URLs, API calls, and search queries silently — the request succeeds but returns wrong results.
Encoding the Entire URL
A complete URL like https://example.com/path?q=hello should never be fully encoded. Doing so encodes the ://, the / separators, and the ? — turning structural URL characters into their percent-encoded forms and producing a string that no browser or server can parse as a URL. Only encode individual components (query parameter values, path segments with special characters) — never the full URL string.
Mixing + and %20 for Spaces
Using + for spaces outside of form-encoded query strings. A + in a URL path is treated as a literal plus sign by most parsers — not a space. Even in query strings, some systems expect %20 and treat + as a literal character. Using %20 everywhere is safer and universally understood.
Forgetting to Encode User Input in URLs
Taking user-submitted text and inserting it directly into a URL without encoding. If the user types coffee & cake, the unencoded ampersand splits the query string. If they type a URL path containing a slash, it creates an unintended path segment. This is both a functionality bug and, in some contexts, a security issue (open redirect vulnerabilities can stem from unencoded URLs).
Real-World Use Cases for URL Encoding and Decoding
API Development & Testing
When sending API requests with query parameters that contain special characters — search terms, filter values, email addresses — encoding the parameter values correctly is what makes the request arrive at the server as intended. Use this tool to quickly encode parameter values before testing an endpoint manually, or to decode an encoded response URL to read it clearly.
Decoding Search Engine URLs
Google, Bing, and other search engines encode search queries in their URLs. When you copy a search result URL to share or analyze it, the query appears as a percent-encoded string. Pasting it into the decoder gives you the original readable search term — useful for SEO research, understanding traffic sources, and debugging tracking parameters.
Link Building & UTM Parameters
UTM parameters added to URLs for campaign tracking frequently contain spaces, ampersands, and special characters in campaign names, medium labels, or source identifiers. Encoding these values correctly prevents the UTM parameter from being misread as a URL structure element — ensuring your analytics data arrives intact and attributed correctly.
Mailto Links with Pre-filled Content
A mailto link with a pre-filled subject and body requires encoding the content correctly. mailto:contact@example.com?subject=Hello+World&body=This+is+a+test — every space, newline, and special character in the subject and body must be encoded for the mailto link to open correctly in different email clients and across operating systems.
Internationalized URLs
URLs containing non-English domain names or paths (Chinese product pages, Arabic category names, accented French or German words) must be correctly percent-encoded for reliable transmission across servers and services that may not support internationalized characters natively. The encoder handles UTF-8 conversion automatically, making it a reliable tool for handling non-English content in URLs.
Security Auditing & Input Validation
Security researchers and developers use URL decoding to analyze potentially malicious URLs — encoded URLs are a common obfuscation technique in phishing attacks, where the destination is obscured through percent-encoding to prevent detection. Decoding the URL reveals the actual destination and any embedded parameters, making it a useful first step in evaluating a suspicious link before clicking it.
How to Use the URL Encoder / Decoder
Paste Your Text or URL
Enter the text you want to encode, or the percent-encoded string you want to decode, into the input field.
Select Encode or Decode
Choose whether you want to encode (convert special characters to %XX) or decode (convert %XX sequences back to readable text).
Get Your Result
The converted output appears instantly. Copy it directly for use in your API call, URL, form, or code.
Important: For encoding, paste only the component value you want to encode — not an entire URL. Encoding a full URL will encode the structural characters (://, /, ?, &) and break it. If you need to encode a search query, paste just the query text, not the full URL containing it.
URL Encoding in Common Programming Languages
Every major programming language has built-in functions for URL encoding and decoding. Knowing which function to use — and the subtle differences between them — prevents the most common encoding bugs.
Key difference to remember: JavaScript's encodeURI() encodes a complete URL (leaves structural characters intact). encodeURIComponent() encodes individual values (encodes everything including &, =, ?). For API parameter values, always use encodeURIComponent(). PHP's rawurlencode() follows RFC 3986 (%20 for spaces); urlencode() uses legacy form encoding (+ for spaces) — use rawurlencode() for modern code.
Pro Tips for Working With URL Encoding
5 Rules That Prevent Encoding Bugs
- Always specify UTF-8 when encoding in code. Most modern languages default to UTF-8, but older systems or certain libraries may default to Latin-1 or another encoding. Always specify the charset explicitly when calling encoding functions to ensure non-ASCII characters are handled correctly across all environments and all users' input.
- Encode values, not the whole URL. A URL has structure that must not be encoded: the scheme (
https://), the host, the path separators (/), the query separator (?), and the parameter separator (&). Only encode the data values within the URL — the content of each parameter, and path segments that contain special characters. Use this tool by pasting the value you want to encode, not the whole URL. - Decode before displaying, encode before transmitting. The right mental model: URLs are stored and transmitted in encoded form. They should be decoded for display to human users (readable text in address bars, logs, dashboards). Any time you need to use a URL value in another URL (e.g., a redirect destination URL as a query parameter), encode the inner URL before embedding it in the outer one.
- Use your browser's console for quick checks. In any browser, open the developer console (F12) and type
encodeURIComponent("your text here")and press Enter to see the encoded output immediately. OrdecodeURIComponent("your%20encoded%20string")to decode. This is the fastest possible encoding check when you need a result in seconds and do not want to open a separate tool. - Watch for double-encoding in redirect chains. When URLs pass through multiple systems — a CMS, a CDN, a tracking script, and then a server — each layer may encode the URL again. The result is
%2520(the encoded form of%25followed by20) where%20should be. If you see%25in a URL that should only have%, you have a double-encoding problem — trace back through the encoding chain and find where it encodes an already-encoded string.
Frequently Asked Questions
Real questions from developers, SEOs, and web users about URL encoding and how it works.
What is the difference between encodeURI and encodeURIComponent in JavaScript?
These two functions encode different sets of characters and are designed for different use cases:
encodeURI(url)— Designed to encode a complete URL. It leaves the structural characters of a URL intact (:,/,?,#,&,=,@) and only encodes characters that are genuinely unsafe in a URL. Use this when you have a full URL and want to make it safe for transmission without breaking its structure.encodeURIComponent(value)— Designed to encode a single URL component value (a query parameter value, a path segment, a fragment). It encodes everything except letters, digits, and- _ . ! ~ * ' ( )— including the structural characters like&,=, and?. Use this for individual values being inserted into a URL.
The most common mistake: using encodeURI for a parameter value. Because it does not encode &, a user-supplied value containing an ampersand will break the query string. Always use encodeURIComponent for any value going into a URL parameter.
Why do I see %20 in some URLs and + in others for spaces?
Both represent spaces but come from different encoding specifications:
%20is the RFC 3986 standard representation of a space — the correct, universal encoding defined for URLs and URIs. It works correctly everywhere: paths, query strings, headers, all contexts.+comes from the olderapplication/x-www-form-urlencodedencoding format used when HTML forms submit data via GET. In this context only, a+is interpreted as a space by the receiving server.
A + in a URL path is a literal plus sign — not a space. Only in query strings, and only when both ends of the transmission understand form encoding, does + mean space. For any modern code you control, use %20 — it is unambiguous across all contexts.
What is double-encoding and how do I fix it?
Double-encoding happens when an already percent-encoded string gets encoded a second time. The first encoding turns a space into %20. The second encoding sees the % character (which is not unreserved) and encodes it as %25, turning %20 into %2520.
When the server decodes %2520, it gets the literal string %20 — not a space. The URL is broken in a way that is very hard to spot visually.
To identify: if you see %25 in a URL that should not contain a literal percent sign, you have double-encoding. The fix: trace back through your code to find where encoding is being applied twice — typically in a pipeline where one function encodes a string and then another function encodes the already-encoded result. Apply encoding exactly once, at the point where the value is being inserted into the URL.
Can I use URL encoding to hide sensitive data in a URL?
No — URL encoding is not encryption and provides zero security. Percent-encoded data is trivially reversible by anyone who copies the URL — either by pasting it into a decoder like this tool, or by typing decodeURIComponent() in any browser console. The entire encoding process is completely standardised and public.
If you need to protect sensitive data (authentication tokens, personal information, financial data), do not put it in URLs at all. Use POST requests with encrypted HTTPS connections and send sensitive values in the request body rather than the URL. For authentication tokens that must be in URLs (OAuth callbacks, password reset links), use short-lived, cryptographically signed tokens — not the sensitive data itself.
Why does my browser show a readable URL but the actual request is encoded?
Modern browsers intentionally display decoded, human-readable URLs in the address bar — even when the actual HTTP request uses percent-encoded form. This is a deliberate usability decision: displaying https://example.com/caf%C3%A9 instead of https://example.com/café would be confusing and unhelpful for most users.
What happens behind the scenes: when you type or click a URL, the browser parses it, identifies any characters that need encoding, encodes them in the actual HTTP request header, but displays the decoded version in the address bar. If you copy the URL from the address bar, modern browsers give you the decoded version. If you copy from the network tab in developer tools, you see the actual encoded form used in the request.
This is why checking encoded URLs requires a tool like this one — the browser's address bar gives you the friendly version, not what is actually being transmitted.
Are URL encoding and HTML encoding the same thing?
No — they are completely different systems designed for different purposes, and confusing them causes bugs. They are not interchangeable.
- URL encoding (percent-encoding) — converts characters to
%XXhexadecimal format for safe transmission in URLs. A space becomes%20, an ampersand becomes%26. - HTML encoding (HTML entity encoding) — converts characters to HTML entity references for safe rendering in HTML documents. An ampersand becomes
&, a less-than sign becomes<, a greater-than sign becomes>.
You use URL encoding when putting values into URLs. You use HTML encoding when outputting values into HTML. When a URL appears inside an HTML attribute (like a link's href), it may need both: the URL itself is percent-encoded, and then the HTML attribute value is HTML-encoded. These are applied at different layers and must not be mixed up or substituted for each other.
Is the URL Encoder / Decoder tool completely free?
Yes — completely free with no account, no sign-up, and no usage limits. Encode and decode as many URLs and strings as you need. This applies to all 47 free tools on DigitalSub Pro — there is no premium tier and no paywall on any feature.