Encode URL

Q: Should I encode the entire URL or just parameter values?

Encode parameter values and path segments individually—never encode the entire URL. Encoding "https://example.com" produces invalid output like "https%3A%2F%2Fexample.com" which breaks routing. The URL structure (scheme, host, delimiters like ?, &, =) must remain unencoded. Only encode the data within parameters and path segments. For example, in "site.com/search?q=hello world", encode "hello world" to "hello%20world" but leave "site.com/search?q=" as-is. Most programming languages provide separate functions: encodeURIComponent() for values, encodeURI() for full URLs (which preserves structure characters). Always use the component-level encoding for data values to avoid breaking URL structure.

Q: Why does my encoded URL have %2B instead of + for plus signs?

Literal plus signs (+) in data must be encoded as %2B to avoid ambiguity with space encoding. In query strings, + is interpreted as space due to application/x-www-form-urlencoded format legacy behavior. If your data contains literal plus signs (like "C++" or "price+shipping"), they must be %2B to distinguish from spaces. The encoder correctly preserves this distinction. For spaces, use %20 in standard URLs or + in form-encoded POST bodies. When building URLs programmatically, encode data values with encodeURIComponent() which produces %2B for plus signs, ensuring correct interpretation by servers. Receivers decode %2B back to literal + and + back to space.

Q: How do I prevent double-encoding errors?

Double-encoding happens when you encode already-encoded text, producing sequences like %2520 (encoded %20) instead of %20. To prevent: check if text contains %XX patterns before encoding—if present, it's likely already encoded. Use programming language functions that track encoding state. When debugging, if decoded output still has many %XX sequences, you've double-encoded. To fix: decode once before re-encoding, or maintain clear separation between encoded and raw data in code. Some frameworks auto-encode, causing double-encoding if you manually encode first. Check framework documentation to see if URL parameters are automatically encoded. Store data in raw form and encode only at the final step before transmission.

Q: Which characters must be encoded in URLs?

RFC 3986 requires encoding characters outside the unreserved set (A-Z, a-z, 0-9, -, ., _, ~). Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have special meaning in URLs and must be encoded when appearing in data values. Spaces, quotes, percent signs, and control characters always need encoding. International characters (non-ASCII) must be UTF-8 encoded then percent-encoded. Context matters: / is reserved in paths but must be encoded in query values. & separates parameters but must be %26 within parameter data. Modern encoders handle this automatically—encode all data values with encodeURIComponent() to ensure compliance. Only unreserved characters and reserved characters used for their structural purpose remain unencoded.

Encode URLs and query parameters instantly to ensure safe transmission in HTTP requests. Convert special characters to percent-encoded format for proper URL handling and API compatibility.

Why Use Encode URL

Unencoded URLs break when they contain spaces, ampersands, or special characters—causing 400 errors and failed requests. This encoder converts unsafe characters to percent-encoded sequences (%20, %26, etc.) that browsers and servers handle correctly. Essential for building query strings programmatically, constructing API requests with user input, creating shareable URLs with parameters, and ensuring cross-platform URL compatibility. Unlike manual encoding, this tool handles all edge cases including international characters, reserved symbols, and multi-byte sequences according to RFC 3986 standards.

Instant encoding: Convert URLs and parameters in milliseconds
RFC 3986 compliant: Follows URI specification for percent-encoding
UTF-8 support: Handles international characters and emojis correctly
Component-aware: Knows which characters to encode in paths vs. query strings
Browser-safe: All encoding happens locally—URLs never transmitted

Encode URL Now →

Choose the Right Variant

This page: URL encoding for safe HTTP transmission
URL Encoder Online: Alternative encoding interface
Decode URL: Opposite operation—decode URLs
URL Decoder Online: Decode for debugging

Step-by-Step Tutorial

Prepare your URL with unencoded parameters: https://example.com/search?q=error rate&category=api errors
Identify parts needing encoding (query values, not structure)
Paste the URL or specific parameter values into the encoder
Click "Encode" to convert special characters
Encoded output: https://example.com/search?q=error%20rate&category=api%20errors
Spaces became %20, structure (?, &, =) remained unchanged
Example with special characters: Input name=John & Jane
Output: name=John%20%26%20Jane (space and ampersand encoded)
Copy encoded URL for use in API requests or href attributes

Encoding Features

Percent-encoding: Converts unsafe characters to %HH format
Reserved character handling: Encodes special chars (/, ?, #, &, =) in data values
Space encoding options: %20 (standard) or + (form data) based on context
UTF-8 encoding: Multi-byte sequences for international characters
Component detection: Different encoding rules for paths, queries, fragments
Validation checking: Warns about already-encoded content to prevent double-encoding

Real-World Use Case

A search feature allows users to enter queries with special characters. A user searches for "C++ programming & tutorials" and the frontend builds a URL: site.com/search?q=C++ programming & tutorials. Clicking the link returns a 400 Bad Request because the unencoded ampersand breaks query parsing—the server sees two parameters: "q=C++ programming " and " tutorials" (invalid). The developer adds URL encoding to the search handler, converting user input before constructing URLs. The encoded version: site.com/search?q=C%2B%2B%20programming%20%26%20tutorials. Now the plus signs (%2B), spaces (%20), and ampersand (%26) are properly encoded. Search results load correctly. Additionally, users can now copy and share search URLs without breaking special characters. Bug reports about search failures drop by 95%. The encoding step prevents all URL-related search issues.

Best Practices

Encode parameter values individually before constructing full URLs
Use %20 for standard URLs; use + for application/x-www-form-urlencoded POST data
Never encode the entire URL including scheme and host (breaks structure)
Check for existing encoding to avoid double-encoding issues
Test encoded URLs in target application to verify compatibility
Encode user-generated content before inserting into URLs

Performance & Limits

URL length: Encodes URLs up to 500,000 characters (browser limits)
Encode speed: Instant encoding for typical URLs (< 5 KB)
Large URLs: 100 KB URL encodes in ~50ms
Expansion ratio: UTF-8 characters expand to 3-9 bytes (%XX sequences)
Batch encoding: Process multiple parameters sequentially
Offline mode: Fully functional offline after page loads

Common Mistakes to Avoid

Encoding entire URLs: Encoding "https://" breaks URL structure—encode values only
Double-encoding: Encoding already-encoded text creates %2520 instead of %20
Wrong space encoding: Using + in paths (works only in query strings)
Not encoding user input: User-provided data can contain injection characters
Encoding reserved chars in structure: Don't encode ?, &, = that separate parameters
Assuming ASCII-only: International users need UTF-8 encoding support

Privacy and Data Handling

All URL encoding happens locally in your browser using JavaScript's native encodeURIComponent() function. Your URLs never leave your device and are never uploaded to any server. The encoder processes URLs entirely in memory without logging or storing content. However, encoded URLs may still contain sensitive data—encoding doesn't hide information, it just makes it URL-safe. Remove API keys, session tokens, or personal information from URLs before sharing encoded versions in documentation, support tickets, or public forums. For URLs with authentication tokens, use this tool in private browsing mode to avoid browser history exposure.

Frequently Asked Questions

Should I encode the entire URL or just parameter values?

Encode parameter values and path segments individually—never encode the entire URL. Encoding "https://example.com" produces invalid output like "https%3A%2F%2Fexample.com" which breaks routing. The URL structure (scheme, host, delimiters like ?, &, =) must remain unencoded. Only encode the data within parameters and path segments. For example, in "site.com/search?q=hello world", encode "hello world" to "hello%20world" but leave "site.com/search?q=" as-is. Most programming languages provide separate functions: encodeURIComponent() for values, encodeURI() for full URLs (which preserves structure characters). Always use the component-level encoding for data values to avoid breaking URL structure.

Why does my encoded URL have %2B instead of + for plus signs?

Literal plus signs (+) in data must be encoded as %2B to avoid ambiguity with space encoding. In query strings, + is interpreted as space due to application/x-www-form-urlencoded format legacy behavior. If your data contains literal plus signs (like "C++" or "price+shipping"), they must be %2B to distinguish from spaces. The encoder correctly preserves this distinction. For spaces, use %20 in standard URLs or + in form-encoded POST bodies. When building URLs programmatically, encode data values with encodeURIComponent() which produces %2B for plus signs, ensuring correct interpretation by servers. Receivers decode %2B back to literal + and + back to space.

How do I prevent double-encoding errors?

Double-encoding happens when you encode already-encoded text, producing sequences like %2520 (encoded %20) instead of %20. To prevent: check if text contains %XX patterns before encoding—if present, it's likely already encoded. Use programming language functions that track encoding state. When debugging, if decoded output still has many %XX sequences, you've double-encoded. To fix: decode once before re-encoding, or maintain clear separation between encoded and raw data in code. Some frameworks auto-encode, causing double-encoding if you manually encode first. Check framework documentation to see if URL parameters are automatically encoded. Store data in raw form and encode only at the final step before transmission.

Which characters must be encoded in URLs?

RFC 3986 requires encoding characters outside the unreserved set (A-Z, a-z, 0-9, -, ., _, ~). Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have special meaning in URLs and must be encoded when appearing in data values. Spaces, quotes, percent signs, and control characters always need encoding. International characters (non-ASCII) must be UTF-8 encoded then percent-encoded. Context matters: / is reserved in paths but must be encoded in query values. & separates parameters but must be %26 within parameter data. Modern encoders handle this automatically—encode all data values with encodeURIComponent() to ensure compliance. Only unreserved characters and reserved characters used for their structural purpose remain unencoded.