URL Encoder
Encode strings into URL-safe format using encodeURIComponent.
Click a card to auto-fill the input
URL Encoding Reference
→%20Space,→%2CComma#→%23Hash&→%26Ampersand=→%3DEquals?→%3FQuestion mark/→%2FSlash:→%3AColon@→%40At sign+→%2BPlus%→%25Percent[→%5BLeft bracket]→%5DRight bracket{→%7BLeft brace}→%7DRight brace"→%22Double quoteWhat Is URL Encoding?
URL encoding (percent-encoding) replaces characters that are not allowed in URLs with %XX sequences, ensuring URLs are safely transmitted across the network without misinterpretation.
This tool uses the browser's native encodeURIComponent function, which encodes all non-alphanumeric characters except -_.!~*'(). It is ideal for encoding strings to be passed as URL query parameter values.
How to Use
- Paste the raw string you want to encode into the left input box
- Click "Encode" — the URL-safe encoded string appears on the right
- Click "Copy Output" to copy the encoded string to your clipboard
Production Scenarios
Encode user-supplied search keywords and filter values before appending them to a URL query string, preventing &, =, and spaces from breaking the parameter structure. Common in list-page filters and search-box navigation links.
In HMAC-SHA256 signing flows, encode parameter keys and values separately with encodeURIComponent before concatenating the signature base string. This prevents = and & inside parameter values from being confused with delimiters, which would cause signature mismatches.
The redirect_uri passed as an authorization request parameter must be encodeURIComponent-encoded before being appended to the full authorization URL. Without encoding, the ? and = inside the redirect URI will be parsed as top-level parameters by the authorization server, causing the callback to miss the authorization code.
Object keys in S3, GCS, or COS may contain Chinese characters, spaces, or special symbols. Encode each path segment individually — keep / separators intact, only encode file/directory names. Encoding slashes will turn the hierarchical key into a flat single-level path.
When interpolating user input into javascript: URLs or onclick attributes, apply URL encoding on top of HTML entity encoding. Double-encoding blocks common bypass techniques attackers use to inject malicious JavaScript through user-controlled URL fragments.
Deep Dive: Comparing Three Encoding Methods
JavaScript provides two URL-encoding functions, and together with HTML form encoding there are actually three encoding methods. encodeURI preserves URI structural characters (# / ? : @ & = + $ , ;) and is meant for encoding an entire URI. encodeURIComponent encodes all non-alphanumeric characters (only -_.!~*'() are left untouched) and is meant for encoding parameter keys and values. The key difference is how they handle &, =, and ? — if you need these characters to be treated as literal data rather than delimiters, you must use encodeURIComponent.
Form encoding (application/x-www-form-urlencoded) is the third and very common method: spaces become + instead of %20, and newlines become %0D%0A. Its behavior differs from both JavaScript functions. For example, the URLSearchParams API in fetch uses form-encoding rules. If your backend verifies signatures using form-encoding but the frontend uses encodeURIComponent, the signatures will never match.
Double encoding is a frequent source of production incidents. The classic scenario: the frontend encodes with encodeURIComponent, the API receives it, Express or Spring MVC middleware auto-decodes query parameters once, the backend developer manually re-encodes in application code, and the final value stored in the database is double-encoded. The fix is a team-wide agreement on the encoding boundary: either "frontend encodes, backend does not decode," or "backend decodes, frontend does not encode" — never both.
Common Mistakes
- Applying encodeURIComponent to a full URL — the :// in the scheme becomes %3A%2F%2F, preventing the browser from navigating to it. The fix: encode only parameter values, or split the URL first and handle each segment separately.
- Repeated encoding across multiple network layers — when a URL passes through Nginx proxy_pass forwarding without proper rewrite or proxy_set_header configuration, the backend may receive a partially decoded or re-encoded URI. How to detect it: if your output contains %25 (the percent sign itself encoded), you have double encoding.
- Confusing path-segment encoding rules with query encoding rules — in a path segment, / is a legal delimiter and should not be encoded, but ?, #, and spaces must be. In a query parameter value, if = and & are part of the value (not delimiters), they must be encoded.
- Forgetting to encode non-ASCII characters — passing Chinese text directly in a URL query string (e.g. ?name=张三) may render correctly in the browser address bar, but intermediate proxies, Nginx access logs, and scrapers may truncate or garble the value.