URL Encoder / Decoder

URL encoding (percent-encoding) converts characters that are not allowed in a URL into a safe format — for example, a space becomes %20, & becomes %26, and accented characters like "é" become %C3%A9. This is required when passing query parameters, embedding URLs inside other URLs, or submitting form data over HTTP. To encode a URL online: paste your text or URL above and switch to Encode mode — the percent-encoded output appears immediately. To decode a URL-encoded string back to readable text, switch to Decode mode. The tool follows RFC 3986 standards and supports UTF-8 and Unicode. All processing is local — no data is uploaded.

Free Online URL Encoder & Decoder

Bitlist's URL Encoder/Decoder is an essential tool for web developers and SEO specialists. It validates and converts URL strings to ensure they are safe for transmission over the internet, adhering to RFC 3986 standards.

Key Features

• Percent-Encoding Validity: Automatically converts unsafe characters (like spaces to %20 or +) to ensure URLs work across all browsers.
• UTF-8 & Unicode Support: Correctly encodes non-ASCII characters, allowing you to debug URLs with foreign languages or emojis (e.g., "café" → caf%C3%A9).
• Instant Feedback: Type or paste your URL, and see the encoded result immediately without page reloads.
• Privacy Guaranteed: All processing happens in your browser's JavaScript engine. Your URLs are never sent to our servers.

Common Use Cases

• Query Parameters: Escape special characters in URL parameters to prevent broken links (e.g., encoding & or ? inside a search query).
• Data Clean-up: Decode messy, unreadable URLs copied from email marketing campaigns or tracking links.
• API Debugging: Encode JSON payloads or tokens before passing them in GET requests.

What is URL Encoding (Percent-Encoding)?

URL encoding (also called percent-encoding) is a mechanism defined in RFC 3986 for encoding special characters in Uniform Resource Identifiers (URIs). URLs can only be transmitted over the internet using the ASCII character set, so any characters outside this range—or characters with special meaning in URLs—must be encoded.

Why URL Encoding is Necessary

URLs have reserved characters with special meanings (like ? for query strings, & for parameter separation, # for fragments). When these characters appear as data rather than URL structure, they must be encoded to prevent misinterpretation:

• Spaces: URLs cannot contain spaces. They must be encoded as %20 or + (in query strings).
• Special Characters: &, =, ?, #, /, :, etc., have structural meaning and must be encoded when used as values.
• Non-ASCII Characters: International characters (é, ñ, 中), emojis (😀), and symbols must be encoded as UTF-8 bytes then converted to percent-encoded form.
• Unsafe Characters: Characters like <, >, ", {, } can cause parsing errors or security issues (XSS attacks) and must be encoded.

Encoding Format

Percent-encoding uses the format: %XX, where XX is the hexadecimal value of the character's byte representation in UTF-8.

Examples:

• Space: → %20 (hexadecimal 0x20 = 32 in decimal)
• Exclamation: ! → %21
• At symbol: @ → %40
• Accented e: é → %C3%A9 (UTF-8 encoding: 0xC3 0xA9)
• Emoji: 😀 → %F0%9F%98%80 (UTF-8: 0xF0 0x9F 0x98 0x80)

Understanding URL Structure

A complete URL consists of multiple components, each with different encoding rules:

https://user:pass@example.com:8080/path/to/resource?key=value&lang=en#section

Component Breakdown:

• Protocol (Scheme): https:// — Specifies the protocol (http, https, ftp, etc.). Never encoded.
• Credentials (optional): user:pass@ — Username and password (deprecated for security reasons). Encode if present.
• Host (Domain): example.com — Domain name or IP address. Do not encode (use Punycode for international domains like münchen.de → xn--mnchen-3ya.de).
• Port (optional): :8080 — Port number. Never encoded.
• Path: /path/to/resource — Resource path on the server. Encode special characters except / (path separator).
• Query String: ?key=value&lang=en — Parameters sent to the server. Encode parameter values, not ?, =, or & separators.
• Fragment (Hash): #section — Client-side anchor. Encode special characters in the fragment identifier.

Reserved vs Unreserved Characters

RFC 3986 defines which characters have special meaning in URLs and which can be used freely:

Reserved Characters (Structural Meaning)

These characters have special meaning and must be encoded when used as data:

Character	Purpose	Encoded As
:	Separates protocol and credentials	%3A
/	Path separator	%2F
?	Starts query string	%3F
#	Starts fragment	%23
&	Separates query parameters	%26
=	Separates parameter key/value	%3D
@	Separates credentials from host	%40
[ ]	IPv6 address delimiters	%5B %5D

Unreserved Characters (Safe to Use)

These characters can appear in URLs without encoding:

• Alphanumeric: A-Z, a-z, 0-9
• Safe Symbols: - (hyphen), _ (underscore), . (period), ~ (tilde)

Unsafe Characters (Always Encode)

These characters can cause parsing errors or security issues and should always be encoded:

• Space: → %20 (or + in query strings, application/x-www-form-urlencoded)
• Quotes: " → %22, ' → %27
• Brackets: < → %3C, > → %3E
• Braces: { → %7B, } → %7D
• Pipe: | → %7C
• Backslash: \ → %5C
• Caret: ^ → %5E
• Backtick: ` → %60

Practical Examples: When and What to Encode

Example 1: Encoding Query Parameters

Scenario: You're building a search URL with user input that contains spaces and special characters.

Unencoded (Broken):

https://example.com/search?q=hello world&category=books & magazines

Why it breaks: The space after "hello" and "books & magazines" confuses the browser. The & in "books & magazines" is interpreted as a parameter separator.

Properly Encoded:

https://example.com/search?q=hello%20world&category=books%20%26%20magazines

Example 2: Encoding Non-ASCII Characters

Scenario: International characters in a URL (French café, Spanish niño, Chinese 中文).

Input:

https://example.com/restaurant/café/menu

Encoded:

https://example.com/restaurant/caf%C3%A9/menu

Explanation: The accented "é" (U+00E9) is encoded as UTF-8 bytes (0xC3 0xA9), then percent-encoded as %C3%A9.

Example 3: Encoding a Redirect URL Parameter

Scenario: You're building an authentication system where the login page redirects to a specific URL after successful login.

Incorrect (Broken):

https://example.com/login?redirect=https://example.com/dashboard?tab=settings

Why it breaks: The ? in the redirect URL is interpreted as starting a new query string, and tab=settings becomes a parameter of the login page, not the dashboard.

Correct (Encoded):

https://example.com/login?redirect=https%3A%2F%2Fexample.com%2Fdashboard%3Ftab%3Dsettings

Breakdown:

• : → %3A
• / → %2F
• ? → %3F
• = → %3D

Example 4: Encoding Emojis in URLs

Scenario: Social media sharing URLs with emojis in titles or descriptions.

Input:

https://example.com/share?title=I ❤️ Pizza 🍕

Encoded:

https://example.com/share?title=I%20%E2%9D%A4%EF%B8%8F%20Pizza%20%F0%9F%8D%95

Explanation: Each emoji is encoded as multiple UTF-8 bytes: ❤️ (U+2764) → %E2%9D%A4%EF%B8%8F, 🍕 (U+1F355) → %F0%9F%8D%95

Example 5: Encoding JSON in GET Requests

Scenario: Passing JSON data in a query parameter for API debugging.

Input JSON:

{"name":"John","age":30,"email":"john@example.com"}

URL with Encoded JSON:

https://api.example.com/user?data=%7B%22name%22%3A%22John%22%2C%22age%22%3A30%2C%22email%22%3A%22john%40example.com%22%7D

Encoded characters: { → %7B, " → %22, : → %3A, @ → %40, etc.

Space Encoding: %20 vs + (Plus Sign)

The encoding of spaces in URLs has two conventions, often causing confusion:

Two Standards for Space Encoding

1. Percent-Encoding (%20): The standard defined in RFC 3986 for URIs. Spaces are encoded as %20 anywhere in the URL (path, query, fragment).
2. application/x-www-form-urlencoded (+): An older standard from HTML form submissions (RFC 1866). In query strings only, spaces can be encoded as + for brevity.

When to Use Each

• Use %20: In URL paths, fragments, and modern APIs. This is the universal standard and works everywhere.
• Use +: Only in query strings when the server expects application/x-www-form-urlencoded format (traditional HTML forms).

Examples

Context	Correct Encoding	Incorrect
URL Path	/hello%20world	/hello+world (wrong context)
Query String (Modern)	?q=hello%20world	—
Query String (Form-Encoded)	?q=hello+world	—
Fragment	#section%20title	#section+title (wrong context)

Best Practice

Always use %20 for consistency. Modern browsers and servers handle %20 universally. Using + only in query strings adds complexity and potential bugs. This tool uses %20 by default.

Common Encoding Mistakes and How to Avoid Them

Mistake 1: Encoding the Entire URL

Problem: Encoding protocol, domain, and path separators breaks the URL structure.

Incorrect:

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello

Correct: Only encode query parameter values:

https://example.com/search?q=hello

Solution: Encode only query parameters, path segments with special characters, or fragment identifiers—never the protocol, domain, or structural separators (://, /, ?, & between parameters).

Mistake 2: Double-Encoding (Encoding Twice)

Problem: Encoding an already-encoded string creates garbled output.

Original: hello world

First Encoding: hello%20world (correct)

Second Encoding (Double-Encoded): hello%2520world (incorrect—%20 became %2520)

Solution: Always decode first before re-encoding. Check if a string is already encoded by looking for % followed by two hex digits.

Mistake 3: Forgetting to Encode Reserved Characters in Values

Problem: &, =, ? in parameter values break parsing.

Incorrect:

?company=Smith&Jones&location=New York

Why it breaks: The & in "Smith&Jones" is interpreted as a parameter separator, making "Jones" a separate (malformed) parameter.

Correct:

?company=Smith%26Jones&location=New%20York

Mistake 4: Encoding Too Little (Security Risk)

Problem: Not encoding <, >, ", ' can expose applications to XSS (Cross-Site Scripting) attacks.

Vulnerable URL:

https://example.com/search?q=<script>alert('XSS')</script>

If reflected in HTML without escaping, this executes malicious JavaScript.

Properly Encoded:

https://example.com/search?q=%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E

Solution: Always encode < → %3C, > → %3E, " → %22, ' → %27 in user input. Never trust unencoded URLs.

Mistake 5: Using the Wrong Character Encoding

Problem: Encoding non-UTF-8 text (like ISO-8859-1 or Windows-1252) creates mojibake (garbled characters).

Example: Spanish "ñ" (U+00F1) in ISO-8859-1 is byte 0xF1. If encoded as %F1, it won't decode correctly as UTF-8.

Solution: Always use UTF-8 encoding before percent-encoding. Modern web standards mandate UTF-8 for URLs.

Mistake 6: Not Decoding Before Processing

Problem: Server-side code processes encoded URLs without decoding, leading to incorrect comparisons or searches.

Example: User searches for "hello world" → URL: ?q=hello%20world → Server searches for literal string "hello%20world" (with encoded space) instead of "hello world".

Solution: Always URL-decode query parameters server-side before using them. Most frameworks (Express.js, Django, Flask, Rails) handle this automatically, but verify.

URL Encoding in Programming Languages

JavaScript

// Encode entire URL components
encodeURIComponent("hello world")  // → "hello%20world"
encodeURIComponent("hello&goodbye") // → "hello%26goodbye"

// Encode full URI (preserves :/?#)
encodeURI("https://example.com/hello world") // → "https://example.com/hello%20world"

// Decode
decodeURIComponent("hello%20world") // → "hello world"

When to use: encodeURIComponent() for query parameter values, encodeURI() for full URLs (rarely needed).

Python

from urllib.parse import quote, unquote, urlencode

# Encode string
quote("hello world")  # → "hello%20world"
quote("hello/world", safe='')  # → "hello%2Fworld" (encode / as well)

# Encode dictionary as query string
urlencode({'q': 'hello world', 'page': 2})  # → "q=hello+world&page=2"

# Decode
unquote("hello%20world")  # → "hello world"

When to use: quote() for individual values, urlencode() for query strings with multiple parameters.

PHP

// Encode
urlencode("hello world");  // → "hello+world" (application/x-www-form-urlencoded)
rawurlencode("hello world");  // → "hello%20world" (RFC 3986)

// Decode
urldecode("hello+world");  // → "hello world"
rawurldecode("hello%20world");  // → "hello world"

Best practice: Use rawurlencode() / rawurldecode() for modern URLs (RFC 3986 compliance).

Java

import java.net.URLEncoder;
import java.net.URLDecoder;
import java.nio.charset.StandardCharsets;

// Encode
URLEncoder.encode("hello world", StandardCharsets.UTF_8);  // → "hello+world"

// Decode
URLDecoder.decode("hello+world", StandardCharsets.UTF_8);  // → "hello world"

Ruby

require 'uri'

# Encode
URI.encode_www_form_component("hello world")  # → "hello+world"
URI.encode_uri_component("hello world")  # → "hello%20world"

# Decode
URI.decode_www_form_component("hello+world")  # → "hello world"

Best Practices for URL Encoding

• Encode only values, not structure: Encode query parameter values, path segments with special chars, but never protocol, domain, or structural separators.
• Use UTF-8: Always encode text as UTF-8 before percent-encoding. UTF-8 is the web standard.
• Avoid double-encoding: Decode before re-encoding to prevent %2520 (double-encoded space).
• Prefer %20 over +: Use %20 for spaces universally instead of mixing + in query strings.
• Encode for security: Always encode user input to prevent XSS attacks. Encode <, >, ", '.
• Test cross-browser: Some older browsers handle encoding differently. Test encoded URLs in Chrome, Firefox, Safari, and Edge.
• Use library functions: Don't implement encoding manually—use built-in functions (encodeURIComponent, quote, urlencode) which handle edge cases correctly.
• Decode server-side: Always decode URL parameters before processing (most frameworks do this automatically).
• Log encoded URLs for debugging: When troubleshooting API calls, log both raw and encoded URLs to identify encoding issues.

Debugging Encoded URLs

Identifying Encoding Issues

Common symptoms of URL encoding problems:

• Broken Links: URL returns 404 or "page not found" due to malformed path or query.
• Missing Parameters: Query parameters disappear because & in a value was interpreted as a separator.
• Garbled Text: Non-ASCII characters display as � or random symbols due to encoding mismatch.
• XSS Warnings: Security scanners flag unencoded <script> or HTML tags in URLs.
• Authentication Failures: Tokens or API keys with special characters are corrupted because they weren't encoded.

Debugging Workflow

1. Decode the URL: Paste the broken URL into this tool and decode it. Check if the decoded version makes sense.
2. Look for Double-Encoding: Search for %25 (encoded %). If present, the URL was double-encoded—decode twice.
3. Inspect Query Parameters: Split on & and =. Ensure all & and = in values are encoded.
4. Check UTF-8 Encoding: If you see multibyte sequences (%C3%A9), verify they decode to the correct UTF-8 characters.
5. Test in Browser Console: Use decodeURIComponent("url_here") in browser console to see decoded output instantly.
6. Compare with Working URL: Find a working URL from the same system and compare encoding patterns.

Tools for Debugging

• Browser DevTools Network Tab: Inspect actual request URLs sent by the browser (often auto-encoded).
• cURL with --trace: curl --trace-ascii - "url" shows exact bytes sent, revealing encoding.
• Online Validators: Use this tool or similar to encode/decode and compare with expected output.
• Diff Tools: Compare encoded URL with expected URL character-by-character to spot differences.

Privacy and Security

This URL Encoder/Decoder operates with complete privacy:

• 100% Client-Side: All encoding and decoding happens locally in your browser using JavaScript. No URLs are uploaded to any server.
• No Logging: We don't log, store, or track the URLs you encode or decode.
• No External Requests: This tool doesn't make any network requests—all processing is local.
• Safe for Sensitive URLs: You can safely encode URLs containing API keys, tokens, or confidential parameters.
• No Account Required: Use anonymously without registration or sign-up.

How It Works: JavaScript functions (encodeURIComponent / decodeURIComponent) built into your browser handle encoding and decoding instantly on your device.

Frequently Asked Questions

What is URL Encoding?

URL encoding (or percent-encoding) is a mechanism defined in RFC 3986 for encoding special characters in URIs. Characters that are not allowed in URLs (like spaces, &, =, ?, #) or non-ASCII characters (accents, emojis, Chinese characters) must be converted to %XX format, where XX is the hexadecimal byte value. This ensures URLs can be transmitted safely across the internet using only ASCII characters.

Difference between %20 and +?

Both encode spaces, but in different contexts. %20 is the universal standard (RFC 3986) for encoding spaces anywhere in a URL (path, query, fragment). + is an older convention from application/x-www-form-urlencoded (HTML forms) used only in query strings. Modern best practice: always use %20 for consistency. This tool uses %20 by default, which works everywhere.

Is my data safe?

Yes, 100%. This tool runs entirely client-side in your browser using JavaScript's built-in encodeURIComponent and decodeURIComponent functions. Your URLs are never uploaded to a server, logged, or tracked. You can verify this by opening your browser's Developer Tools (Network tab) and observing zero network requests when encoding/decoding. It's completely safe for sensitive URLs containing API keys, tokens, or confidential data.

Should I encode the whole URL?

No. Only encode parameter values and path segments with special characters—never the protocol (https://), domain (example.com), or structural separators (/, ?, & between parameters). Encoding the entire URL breaks its structure. Example: Encode ?q=hello world to ?q=hello%20world, not %3Fq%3Dhello%20world (which is broken).

Why does decoding show weird characters?

This usually indicates one of three issues: (1) Double-encoding: The URL was encoded twice—decode it twice. Look for %25 (encoded %). (2) Wrong character encoding: The text was encoded as ISO-8859-1 or Windows-1252 instead of UTF-8—try decoding with the correct charset. (3) Corrupted URL: Copy-paste errors or incomplete encoding can create invalid byte sequences. Re-encode from the original source.

Can I encode spaces as plus signs?

Technically yes, but only in query strings (application/x-www-form-urlencoded). However, %20 is universally safer. Using + works in query strings but fails in URL paths and fragments. Modern APIs and servers expect %20. This tool uses %20 by default to ensure compatibility across all URL contexts.

What are reserved characters in URLs?

Reserved characters have special structural meaning in URLs and must be encoded when used as data: : (protocol separator), / (path separator), ? (query start), # (fragment start), & (parameter separator), = (key-value separator), @ (credentials separator), [ ] (IPv6 brackets). When these characters appear in parameter values or data, encode them: & → %26, = → %3D, ? → %3F, etc.

How do I encode international characters (Chinese, Arabic, Emoji)?

Non-ASCII characters are encoded as UTF-8 bytes, then percent-encoded. This tool handles this automatically. Example: Chinese "中" (U+4E2D) → UTF-8 bytes (0xE4 0xB8 0xAD) → %E4%B8%AD. Emoji "😀" (U+1F600) → UTF-8 bytes (0xF0 0x9F 0x98 0x80) → %F0%9F%98%80. Simply paste the international text and click "Encode"—the tool converts to UTF-8 first, then percent-encodes.

What's the difference between encodeURI and encodeURIComponent in JavaScript?

encodeURIComponent() encodes all special characters except unreserved chars (A-Z, a-z, 0-9, -, _, ., ~). Use for query parameter values. encodeURI() preserves URL structure chars (:, /, ?, #, &) so you can encode a full URL. However, this is rarely needed—usually encode only parameter values with encodeURIComponent(). This tool uses encodeURIComponent() logic for maximum safety.

Can URL encoding prevent XSS attacks?

Partially. URL encoding prevents some XSS vectors by encoding < → %3C, > → %3E, " → %22, making injected scripts appear as text. However, encoding alone is not sufficient. Always: (1) Encode user input in URLs, (2) HTML-escape output when rendering in web pages, (3) Use Content Security Policy (CSP) headers, (4) Validate and sanitize input server-side. Defense in depth is essential—encoding is one layer, not the entire solution.

Why do some URLs work without encoding?

Modern browsers auto-encode URLs typed in the address bar or clicked in links—they silently convert spaces to %20 and encode international characters. However, this is a convenience feature, not a guarantee. When constructing URLs programmatically (JavaScript, APIs, form submissions), you must manually encode. Never rely on automatic encoding—always encode explicitly to ensure compatibility across all browsers and systems.