URL Encoder & Decoder

URL Encoder & Decoder

Encode and decode text for safe use in URLs, query strings, and parameters instantly. Convert special characters into percent-encoded format or decode URL-encoded strings back to readable text. Perfect for building API requests, debugging links, and handling query parameters.

Uses percent-encoding (%HH) with UTF-8 for non-ASCII characters, following RFC 3986 standards for URI encoding.

How to URL-Encode or Decode

Using our URL encode decode tool is simple:

1. Paste your input into the text field (either plain text to encode or URL-encoded text to decode)
2. Choose your operation: Encode or Decode
3. Select encoding mode: Encode full URL (preserves structural characters like :, /, ?) or Encode component (encodes everything except unreserved characters for parameter values)
4. Copy the output to use in your URLs, API requests, or applications

The URL encoder automatically processes your input and displays results instantly, handling both ASCII and UTF-8 characters correctly.

What is URL Encoding (Percent-Encoding)?

URL encoding, also called percent-encoding, is a mechanism for representing characters in Uniform Resource Identifiers (URIs) and URLs in a format that can be safely transmitted over the internet. This encoding is defined in RFC 3986, the standard specification for URI generic syntax.

The core principle is simple: certain characters have special meaning in URLs and need to be encoded when used as data rather than structural delimiters. Percent-encoding replaces these characters with a percent sign (%) followed by two hexadecimal digits representing the character's byte value. For example, a space character becomes %20, a question mark becomes %3F, and an ampersand becomes %26.

Why encoding is necessary: URLs can only contain certain characters from the ASCII character set. Reserved characters like ?, &, =, #, and / serve as structural delimiters that define different parts of a URL (query parameters, fragments, path segments). When you want to include these characters as actual data in a URL rather than as delimiters, they must be percent-encoded to avoid ambiguity.

UTF-8 encoding for non-ASCII characters: Characters outside the basic ASCII range (like e, n, , or emoji) are encoded as UTF-8 bytes first, then each byte is represented as a percent-encoded sequence. This is why a single non-ASCII character often becomes multiple %HH groups. For instance, the character "e" (U+00E9) is encoded as two UTF-8 bytes: C3 and A9, resulting in %C3%A9 in the final URL.

The percent-encoding mechanism ensures that URLs remain compatible across all systems, browsers, and servers, regardless of the original character set or language.

Reserved vs Unreserved Characters: Quick Guide

Understanding which characters need encoding depends on their classification in the URI specification.

Unreserved characters can appear in URLs without encoding because they have no special meaning. These include uppercase letters (A-Z), lowercase letters (a-z), digits (0-9), and a few punctuation marks: hyphen (-), underscore (_), period (.), and tilde (~). These characters are safe to use anywhere in a URL without modification.

Reserved characters have special meaning as structural delimiters and must be encoded when used as data. The reserved character set includes: colon (:), forward slash (/), question mark (?), hash/pound (#), square brackets ([]), at sign (@), exclamation point (!), dollar sign ($), ampersand (&), apostrophe ('), parentheses (()), asterisk (*), plus (+), comma (,), semicolon (;), and equals (=).

However, whether a reserved character needs encoding depends on context. For example, the slash (/) naturally appears in URL path segments and doesn't need encoding there, but if you want a literal slash character inside a query parameter value, it must be encoded as %2F to prevent it from being interpreted as a path separator.

Common encodings you'll see frequently: Space becomes %20, question mark (?) becomes %3F, ampersand (&) becomes %26, equals (=) becomes %3D, hash (#) becomes %23, slash (/) becomes %2F, colon (:) becomes %3A, and at sign (@) becomes %40.

The key principle is that reserved characters must be encoded when they appear as data rather than as structural elements of the URL itself.

Encode a Full URL vs a URL Component

There's an important distinction between encoding an entire URL and encoding individual components, and using the wrong approach can break your URLs or fail to properly escape special characters.

Encoding a full URL preserves the structural delimiters that define the URL's syntax. When you encode a complete URL like "https://example.com/path?query=value", you want to keep the protocol separator (://), path slashes (/), query indicator (?), and parameter separator (&) intact. Only characters that shouldn't appear in those contexts get encoded. This corresponds to JavaScript's encodeURI function, which encodes spaces and some special characters but leaves URL structure intact.

Encoding a URL component (specifically parameter values) encodes more aggressively because the text will be inserted into an existing URL structure where reserved characters could cause parsing problems. When encoding a parameter value that will appear after the equals sign in a query string, you must encode characters like &, =, ?, #, and / even though these are valid URL characters in other contexts. This prevents them from being misinterpreted as query parameter separators or other structural elements. This corresponds to JavaScript's encodeURIComponent function.

Practical example: Imagine you want to create a URL with a parameter whose value is "data?test=123&more". If you don't encode the parameter value, your URL might look like "https://api.example.com/search?query=data?test=123&more", which will be incorrectly parsed because the browser sees multiple question marks and ampersands. Properly encoding the component gives you "https://api.example.com/search?query=data%3Ftest%3D123%26more", where the special characters are escaped and won't interfere with URL parsing.

Best practice: When building URLs programmatically, encode individual parameter values using component encoding, then assemble them into the complete URL. Don't encode the entire URL after construction, as this will break the structural delimiters.

Why Spaces Sometimes Become %20 and Sometimes +

The encoding of space characters is one of the most confusing aspects of URL encoding because you'll encounter both %20 and + in different contexts, and both are technically correct depending on the situation.

%20 is standard percent-encoding for a space character. Following RFC 3986, the space character (ASCII 32) is encoded as %20. This is the universal encoding that works everywhere in URLs: in path segments, query parameters, fragments, and any other URL component. When you use a general-purpose URL encoder or JavaScript's encodeURIComponent function, spaces become %20.

The plus sign (+) represents spaces specifically in application/x-www-form-urlencoded format, which is how HTML forms serialize data when submitted via GET or POST requests. In this encoding scheme, spaces in form field values are converted to plus signs rather than %20 for historical reasons related to how early web forms worked. This is why query strings from HTML forms often show "hello+world" instead of "hello%20world".

The practical difference: When you're manually constructing API requests or working with modern web applications, use %20 for spaces. When you're dealing with data from HTML forms or query strings that originated from form submissions, you'll see plus signs for spaces. Most URL decoders handle both formats correctly, converting + to space when decoding form-encoded content and %20 to space in all contexts.

Important note for decoder behavior: Our tool's decoder treats the plus sign (+) as a space when decoding query strings, matching the behavior expected for form-encoded data. If you need a literal plus sign in your decoded output, it should be encoded as %2B in the URL.

The key takeaway is that both encodings are correct in their respective contexts, but %20 is the more universal choice for general URL encoding.

Examples

Here are practical examples showing URL encoding and decoding in action:

Encode a parameter value containing special characters Input: name=John Doe&age=25 Encoded: name%3DJohn%20Doe%26age%3D25

This shows why encoding matters. Without encoding, the ampersand and equals signs would be interpreted as query parameter separators rather than part of the data value.

Encode a URL path containing spaces Input: /products/smart phone cases Encoded: /products/smart%20phone%20cases

Spaces in path segments must be encoded to create valid URLs.

Encode query parameters for an API request Input: https://api.example.com/search?q=hello world&filter=price>100 Encoded: https://api.example.com/search?q=hello%20world&filter=price%3E100

The greater-than sign (>) gets encoded to prevent parsing issues.

Decode percent-encoded characters Input: user%40example.com%2Fprofile%3Fid%3D123 Decoded: user@example.com/profile?id=123

This shows %40 (at sign), %2F (slash), %3F (question mark), and %3D (equals) being decoded.

Decode form-encoded query string with plus signs Input: search=hello+world&category=home+garden Decoded: search=hello world&category=home garden

Plus signs are correctly converted to spaces in form-encoded data.

Encode non-ASCII characters (UTF-8) Input: resume.pdf Encoded: r%C3%A9sum%C3%A9.pdf

Each accented character (e) becomes two percent-encoded bytes (%C3%A9) because it's encoded as UTF-8.

When You Need a URL Encoder/Decoder

URL encoding and decoding are essential for various web development and debugging tasks:

Building API requests requires proper encoding of query parameters. When you construct URLs for REST APIs, OAuth signatures, or webhook callbacks, every parameter value must be correctly encoded. Special characters like ampersands, equals signs, slashes, and spaces in parameter values will break your request if not encoded. OAuth signature generation is particularly strict about encoding, requiring exact RFC 3986 compliance, and even small encoding mismatches will cause authentication failures.

Debugging redirect URLs and tracking links often involves decoding heavily encoded URLs to understand what data they contain. Marketing tracking pixels, analytics parameters, and redirect chains frequently use URL encoding multiple times, resulting in URLs full of percent-encoded characters. A URL decoder helps you see what's actually being passed through these systems.

Handling user input in web applications requires encoding before inserting text into URLs. When users enter search queries, filter criteria, or any text that becomes part of a URL, you must encode their input to prevent breaking the URL structure and to protect against URL-based security vulnerabilities.

Working with international content means dealing with non-ASCII characters that must be UTF-8 encoded. Product names, user names, file names, and search terms in languages other than English need proper encoding to work correctly across all systems.

Parsing and analyzing query strings from various sources often requires decoding to extract the actual values. Log files, analytics reports, and server access logs show encoded URLs that need to be decoded for human-readable analysis.

Troubleshooting Common Issues

Here are solutions to frequent URL encoding and decoding problems:

"My decoded text looks wrong or has plus signs instead of spaces": This happens when plus signs (+) in the encoded URL should be treated as spaces but your decoder isn't configured for form-encoded content. In application/x-www-form-urlencoded format (HTML forms and many query strings), the plus sign represents a space character. Our decoder handles this correctly, converting + to space when decoding query strings. If you need a literal plus sign, it should be encoded as %2B.

"Different URL encoding tools give me different output": This is usually caused by three factors. First, tools may use different encoding modes - encoding a full URL preserves structural characters like colons and slashes, while encoding a component encodes these characters too. Second, space handling varies: some tools output %20 while others output + depending on whether they're using standard percent-encoding or form encoding. Third, UTF-8 encoding is standard but older tools might use different character encodings, producing different byte sequences for non-ASCII characters.

"Double-encoding problems (seeing %2520 instead of %20)": Double-encoding occurs when already-encoded text gets encoded again. For example, %20 (an encoded space) gets encoded again as %2520 (where %25 is the encoding of the percent sign itself). This typically happens when you encode a URL, then accidentally encode it again, or when data passes through multiple systems that each apply encoding. To fix this, decode the URL one pass at a time. Never encode text that's already encoded unless you specifically need multiple encoding levels.

"My API request fails with encoding errors": OAuth signatures and some APIs require strict RFC 3986 encoding where certain characters must be encoded in specific ways. Make sure you're using component encoding (not full URL encoding) for parameter values. Verify that your encoding matches what the API expects - some APIs are strict about uppercase vs lowercase hex digits in percent-encoding (%2F vs %2f), though both should be treated identically according to standards.

"Special characters in file names cause download issues": File names in URLs (like attachment downloads) need careful encoding. Spaces, quotes, and special punctuation must all be encoded. Use component encoding for the file name portion, and ensure your server sends proper Content-Disposition headers with encoded file names.

"Encoding breaks my URL structure": If colons, slashes, or other structural characters get encoded when they shouldn't be, you probably encoded the entire URL instead of encoding individual components before assembly. Build your URL by encoding only the variable parts (parameter values, dynamic path segments), then combine them with the structural elements.

Frequently Asked Questions

What is URL encoding and why is percent-encoding needed?

URL encoding, technically called percent-encoding, is the process of converting characters into a format safe for URLs by representing them as percent signs followed by hexadecimal values. It's defined in RFC 3986 as the standard way to include special characters in URIs. Encoding is necessary because URLs can only contain a limited set of ASCII characters, and certain characters have special structural meaning (like ? for queries, & for parameter separators). When these characters appear as actual data, they must be encoded to avoid ambiguity and parsing errors.

Which characters must be encoded in URLs?

Characters that must be encoded depend on context, but generally fall into two categories. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have special meaning as URL delimiters and must be encoded when used as data. Non-ASCII characters (anything outside basic ASCII, including accented letters, non-Latin scripts, and emoji) must always be encoded as UTF-8 byte sequences. Unreserved characters (A-Z, a-z, 0-9, hyphen, underscore, period, tilde) never need encoding. Additionally, space characters must be encoded, typically as %20.

Why does a space character sometimes appear as %20 and sometimes as a plus sign (+)?

This is because of two different encoding standards. Standard percent-encoding following RFC 3986 represents space as %20, which is universally correct for all URL contexts. However, the plus sign (+) is used for spaces specifically in application/x-www-form-urlencoded format, which is how HTML forms serialize data. When you see query strings like "search=hello+world", that's form encoding. Modern URL encoding typically uses %20, but many decoders convert both + and %20 to spaces when decoding query parameters.

What's the difference between encoding a full URL versus encoding a parameter value?

Encoding a full URL preserves structural delimiters that define the URL's syntax, keeping characters like :, /, ?, and & intact while encoding only problematic characters. Encoding a parameter value (URL component encoding) is more aggressive, encoding reserved characters that might interfere with query string parsing, including &, =, ?, #, and /. When building URLs, you should encode individual parameter values using component encoding, then assemble them into the complete URL structure rather than encoding the entire assembled URL.

What is encodeURIComponent versus encodeURI in JavaScript?

These are two JavaScript functions for URL encoding with different purposes. encodeURI is designed for encoding complete URLs while preserving URL structure - it doesn't encode characters like :, /, ?, and & that are valid URL syntax. encodeURIComponent is designed for encoding individual URL components like parameter values - it encodes everything except unreserved characters (A-Z, a-z, 0-9, hyphen, underscore, period, tilde). For query parameter values, always use encodeURIComponent to ensure special characters don't break your URL structure.

Does this URL encoder use UTF-8 encoding?

Yes, our URL encoder uses UTF-8 encoding for all characters, which is the standard for modern web applications. When you encode non-ASCII characters, they're first converted to UTF-8 bytes, then each byte is represented as a percent-encoded sequence (%HH). For example, the Euro symbol () is encoded as three UTF-8 bytes: E2, 82, AC, resulting in %E2%82%AC. UTF-8 encoding ensures proper handling of international text, emoji, and special symbols.

Does the decoder treat plus signs as spaces?

Yes, our decoder converts plus signs (+) to spaces when decoding, matching the expected behavior for application/x-www-form-urlencoded content. This is standard for query strings and form data. If you need a literal plus sign in your decoded output, the plus should be encoded as %2B in the source URL. Our decoder handles both + (as space) and %20 (as space) correctly.

Can URL encoding protect against security vulnerabilities?

Proper URL encoding is essential for security, though it's not a complete security solution. Encoding user input before including it in URLs helps prevent URL-based injection attacks where malicious characters could manipulate your application. However, you still need additional security measures like input validation, output encoding in different contexts (HTML, JavaScript), and server-side security controls. URL encoding is one layer of defense in a comprehensive security strategy.

Why do international characters become multiple percent-encoded groups?

Non-ASCII characters are encoded as UTF-8 before percent-encoding. Most non-ASCII characters require multiple bytes in UTF-8 encoding. For instance, characters from Latin extended sets typically need 2 bytes, characters from most Asian scripts need 3 bytes, and emoji typically need 4 bytes. Each UTF-8 byte becomes one percent-encoded group (%HH), so a single character might appear as %C3%A9 (2 bytes), %E4%B8%AD (3 bytes), or even longer sequences.

Does ToolPoint store my input when I encode or decode URLs?

No, we do not store, save, or transmit your input to our servers. All URL encoding and decoding happens locally in your browser using JavaScript. Your data never leaves your device. Once you close the page or clear your input, your data is permanently gone. This ensures complete privacy for sensitive URLs, API keys, or confidential data you're encoding or decoding.

What happens if I encode already-encoded text?

Encoding text that's already encoded results in double-encoding. For example, a space encoded as %20 gets encoded again as %2520 (where the percent sign itself becomes %25). This is almost never what you want and will cause your URLs to break. If you accidentally double-encode, you need to decode the text multiple times (once for each encoding layer) to get back to the original. Always check whether your input is already encoded before applying encoding again.

How do I handle encoding in OAuth signatures?

OAuth signature generation requires strict RFC 3986-compliant encoding of all parameter values. Every parameter must be percent-encoded using component encoding rules before being included in the signature base string. Even characters that seem safe must follow exact encoding rules. OAuth is very sensitive to encoding mismatches - if your encoding doesn't exactly match what the OAuth server expects, signature verification will fail and your request will be rejected. Always use proper URL component encoding for OAuth parameters.