Loading...
Loading...
Encode and decode URLs with percent-encoding — instantly in your browser.
Use URL Encoder / Decoder to make URL parts safe for query strings, redirects, callbacks, and API tests. Encoding is about URL syntax, not secrecy: it protects reserved characters from being misread by a parser, but anyone can decode it. The safest habit is to encode the specific component you are placing into a URL and keep an original copy for comparison.
Decode until the value stops changing, then encode once at the correct layer.
Encode individual parameter values with encodeURIComponent-style encoding instead of blindly encoding the whole URL.
Remember that URL encoding is reversible; remove tokens, emails, and private identifiers from examples.
Check whether the destination expects form-style query encoding or RFC 3986 percent encoding.
URL encoding and decoding happens in the browser tab. Do not paste real access tokens, password reset links, private callback URLs, or customer identifiers on shared devices or in screenshots.
Decide whether you are encoding a full URL, a path segment, or a single query parameter value.
Run the conversion and check reserved characters such as ?, &, =, #, /, spaces, and non-ASCII text.
Use the result in the redirect, API request, or browser address bar and keep the original for comparison.
Encode a search phrase such as red shoes and socks before adding it to a q parameter.
Decode a nested redirect parameter one layer at a time to inspect the true destination without treating encoding as encryption.
encodeURI() encodes a full URL but leaves reserved characters (: / ? # & =) intact. encodeURIComponent() encodes everything except letters, digits, and - _ . ~ — use it for query parameter values.
In URL query strings (application/x-www-form-urlencoded), spaces become +. In URL paths and other contexts (RFC 3986), spaces become %20. Both are valid in their respective contexts.
Search engines decode URLs for display but handle encoded URLs correctly. For readability, use human-readable URL slugs and only encode special characters when necessary.
Double encoding happens when an already-encoded string is encoded again (e.g., %20 becomes %2520). Decode until the output stops changing, then encode once.
Characters outside the "unreserved" set (A-Z, a-z, 0-9, -, _, ., ~) should be percent-encoded. Common examples include spaces (%20), ampersand (%26), equals (%3D), hash (%23), and non-ASCII characters like accented letters.
No. URL percent encoding is reversible formatting for transport, not encryption or access control, so never rely on it to protect secrets.
Usually encode the specific component, such as a query parameter value, instead of the entire URL. Encoding the whole URL can hide separators like question marks and ampersands that the destination parser needs.
Look for percent signs that have become percent-two-five sequences, such as %2520 instead of %20. Decode one layer at a time, compare the result with the expected original, then encode once for the final destination.
No. URL encoding is reversible formatting, not privacy protection. Treat encoded reset links, callback URLs, emails, and tokens as sensitive if the decoded value would reveal private information.
Some form-style query parsers treat plus as a space, while path and RFC-style percent encoding use %20 for spaces. Check the receiving API documentation before changing plus signs manually.