Why do I see %2B instead of + in URL encoder output?

The plus sign has special meaning in URLs as a space character in form-encoded data. If you want a literal plus sign in your data, it must be percent-encoded as %2B to avoid ambiguity with spaces.

How do I detect double encoding in URLs?

Look for patterns like %2520 (encoded %20). If decoding once still shows many %XX sequences, it's double-encoded. Always decode completely before re-encoding to avoid this issue.

URL Encoder Online

Q: Why do I see %2B instead of + in output?

The plus sign (+) has special meaning in URLs—it represents a space in application/x-www-form-urlencoded format (traditional HTML forms). If you want a literal plus sign in your data (like "1+1"), it must be percent-encoded as %2B to avoid ambiguity. Modern URLs (query strings) use %20 for spaces, so a literal plus sign always becomes %2B . This prevents confusion: is "price+10" meant to be "price 10" or "price+10"? Encoding the plus ensures the correct interpretation.

Q: Should I encode the full URL or just parameters?

Encode only the parameter values and path segments—never the protocol ( https:// ), domain ( example.com ), or structural separators ( ? , & , = ). For example, given https://api.com/search?q=hello world , encode only "hello world" to get ?q=hello%20world . Encoding the entire URL would break it: https%3A%2F%2Fapi.com%2Fsearch%3Fq%3Dhello%20world is no longer a valid URL. Use this tool's component-aware mode to encode just the values you need.

Q: How do I detect double encoding?

Double encoding happens when you encode an already-encoded URL. Look for patterns like %2520 (percent-encoded %20 ) or %253D (percent-encoded = ). If you decode the URL once and still see many %XX sequences, it's likely double-encoded. To fix: decode the URL completely, verify it looks correct, then re-encode it once. Double encoding breaks URLs because servers decode once and receive gibberish: %2520 decodes to %20 instead of a space. Always decode before re-encoding to avoid this issue.

Q: Which specification governs percent encoding?

RFC 3986 is the official specification for URI syntax and percent encoding. It defines which characters are reserved ( :/?#[]@!$&'()*+,;= ), unreserved (A-Z, a-z, 0-9, -_.~ ), and must be percent-encoded (everything else). RFC 3986 replaces older standards like RFC 2396 and RFC 1738. Modern browsers, servers, and HTTP libraries all follow RFC 3986 rules. When in doubt about encoding behavior, refer to RFC 3986 sections 2.1 (Percent-Encoding) and 2.2 (Reserved Characters) for authoritative guidance.

Encode URLs with percent encoding (RFC 3986) for safe transmission in query strings, redirects, and API calls. Convert spaces, special characters, and UTF-8 text to %20-style encoded URLs instantly in your browser.

Why Use URL Encoder Online

URLs can only contain certain ASCII characters. Spaces, symbols, international characters, and special punctuation break URLs unless properly encoded. This tool applies percent encoding to make URLs safe for HTTP requests, browser redirects, and API parameters.

Query parameters: Encode search terms, user input, and filter values with spaces or symbols
Redirect URLs: Safely embed destination URLs in redirect parameters
API calls: Prepare URL-safe strings for REST APIs and webhooks
Form submissions: Encode GET form data with special characters
Browser-safe: All encoding happens locally—no server uploads

Encode URL Now →

Choose the Right Variant

This page: Quick URL encoding for query strings and parameters
URL Decoder Online: Decode percent-encoded URLs back to readable text
Percent Encode: RFC 3986 percent encoding for URIs
Encode URL: Fast URL component encoding

Step-by-Step Tutorial

Paste the URL or text you want to encode into the input field
Example input: https://example.com/search?q=hello world&sort=price+desc
Click "Encode" to apply percent encoding
Copy the encoded output: https://example.com/search?q=hello%20world&sort=price%2Bdesc
Use the encoded URL in HTTP requests, redirect parameters, or API calls
Test the URL in your browser or API client to verify it works correctly

Key Features & Encoding Rules

Spaces: Encoded as %20 (or + in form data context)
Special characters: !*'();:@&=+$,/?#[] encoded to %XX hex codes
UTF-8 support: International characters (é, 中, 한) properly encoded
Component-aware: Option to encode query values only or full URLs
RFC 3986 compliant: Follows official URI syntax standard
Safe characters: Letters (A-Z, a-z), numbers (0-9), and -_.~ remain unencoded

URL Encoding Logic

Percent Encoding: %HH where HH is hexadecimal byte value
Example: space (ASCII 32) → %20, @ symbol → %40
Maximum Expansion: encoded_length ≤ original_length × 3
Worst case: each byte becomes %XX (3 characters)
Reserved Characters (RFC 3986): :/?#[]@!$&'()*+,;=
Must be percent-encoded unless used for their reserved purpose
Unreserved Characters: A-Z a-z 0-9 - _ . ~
Never need encoding—always safe in URLs

Real-World Use Case

A marketing team builds a campaign tracking URL with UTM parameters containing spaces and special characters: utm_campaign=Summer Sale 2024 (50% off!). Without encoding, the URL breaks because browsers interpret spaces as parameter separators and parentheses as invalid characters. They paste the campaign name into the encoder, get Summer%20Sale%202024%20%2850%25%20off%21%29, and build the tracking URL: https://example.com/?utm_campaign=Summer%20Sale%202024%20%2850%25%20off%21%29. The URL now works correctly in all email clients, social media posts, and analytics tools. Total time saved: 15 minutes of debugging why campaign links weren't working.

Best Practices

Encode only the query parameter values—don't encode the entire URL including protocol and domain
Check if spaces should be %20 or + (form-urlencoded uses +, URLs use %20)
Avoid double-encoding: decode first if you're re-encoding an already-encoded URL
Test encoded URLs in the target system before deploying to production
Use UTF-8 encoding for international characters before percent encoding
Remove or encode API keys in URLs before sharing in documentation or chat

Performance & Limits

URL length: Encodes URLs up to 2MB in modern browsers
Processing speed: Instant encoding for typical query strings (< 1KB)
Large inputs: URLs over 100KB may take 1-2 seconds to encode
Browser compatibility: Works in Chrome, Firefox, Safari, and Edge
Offline mode: Fully functional offline after page loads

Common Mistakes to Avoid

Encoding the whole URL: Don't encode https:// or the domain—only query parameters and path segments
Wrong space encoding: Use %20 in URLs, + only in application/x-www-form-urlencoded
Double encoding: Encoding an already-encoded URL produces gibberish like %2520 (encoded %20)
Missing UTF-8 step: Encode international text to UTF-8 bytes before percent encoding
Ignoring reserved chars: &, =, ? have special meaning in URLs—encode them in values

Privacy and Data Handling

All URL encoding happens locally in your browser using JavaScript. Your URLs and query parameters never leave your device and are never sent to any server. However, encoded URLs often contain sensitive data (API keys, tokens, user IDs) that remain visible in browser history, server logs, and network traffic. Always remove sensitive parameters before sharing URLs in documentation, support tickets, or public forums. For maximum security, use this tool in private browsing mode when encoding URLs with credentials or personal data.

Frequently Asked Questions

Why do I see %2B instead of + in output?

The plus sign (+) has special meaning in URLs—it represents a space in application/x-www-form-urlencoded format (traditional HTML forms). If you want a literal plus sign in your data (like "1+1"), it must be percent-encoded as %2B to avoid ambiguity. Modern URLs (query strings) use %20 for spaces, so a literal plus sign always becomes %2B. This prevents confusion: is "price+10" meant to be "price 10" or "price+10"? Encoding the plus ensures the correct interpretation.

Should I encode the full URL or just parameters?

Encode only the parameter values and path segments—never the protocol (https://), domain (example.com), or structural separators (?, &, =). For example, given https://api.com/search?q=hello world, encode only "hello world" to get ?q=hello%20world. Encoding the entire URL would break it: https%3A%2F%2Fapi.com%2Fsearch%3Fq%3Dhello%20world is no longer a valid URL. Use this tool's component-aware mode to encode just the values you need.

How do I detect double encoding?

Double encoding happens when you encode an already-encoded URL. Look for patterns like %2520 (percent-encoded %20) or %253D (percent-encoded =). If you decode the URL once and still see many %XX sequences, it's likely double-encoded. To fix: decode the URL completely, verify it looks correct, then re-encode it once. Double encoding breaks URLs because servers decode once and receive gibberish: %2520 decodes to %20 instead of a space. Always decode before re-encoding to avoid this issue.

Which specification governs percent encoding?

RFC 3986 is the official specification for URI syntax and percent encoding. It defines which characters are reserved (:/?#[]@!$&'()*+,;=), unreserved (A-Z, a-z, 0-9, -_.~), and must be percent-encoded (everything else). RFC 3986 replaces older standards like RFC 2396 and RFC 1738. Modern browsers, servers, and HTTP libraries all follow RFC 3986 rules. When in doubt about encoding behavior, refer to RFC 3986 sections 2.1 (Percent-Encoding) and 2.2 (Reserved Characters) for authoritative guidance.