URL Encoder & Decoder

Double URL encoding happens when already encoded text gets encoded again. For example, / becomes %2F after one encoding, and %2F becomes %252F after a second encoding because the percent sign itself becomes %25. This often happens when a backend, frontend, redirect rule, or API client all try to be helpful and encode the same value. It can break routes and query parameters. To debug it, decode once and check whether percent sequences still remain. Encode only at the boundary where the value enters the URL.

Modern URLs encode non-ASCII characters using UTF-8 bytes and percent-encoding. For example, a space may become %20, and characters from Hindi, Japanese, or emoji become multiple percent-encoded byte sequences. In JavaScript, use encodeURIComponent for query parameter values or path segment values, not manual replacement. Browsers may display friendly Unicode in the address bar, but the actual request is safely encoded. Always encode the value, not the whole URL blindly, because characters like ?, &, #, and / have special structural meanings.

URL encoding protects data inside a URL. It uses percent sequences like %20, %2F, and %3F so special URL characters do not change the path, query, or fragment. HTML encoding protects text inside HTML. It uses character references like <, >, and & so the browser does not treat text as markup. Use URL encoding for links and query parameters. Use HTML encoding when placing user text on a web page. They solve different problems, and using one in place of the other can cause bugs or security issues.

First convert the object to a JSON string with JSON.stringify. Then encode that string as a query parameter value using encodeURIComponent. For example, data={"id":7,"name":"Asha"} becomes a safe encoded value that will not break at quotes, braces, commas, spaces, or ampersands. On the receiving side, read the parameter, run decodeURIComponent if your framework has not already decoded it, then JSON.parse it. For large JSON, avoid query parameters because URLs have practical length limits; use a POST body instead.

It depends where the characters appear. If & and = are separators between query parameters, do not encode them because they define the URL structure. If they are part of a value, encode the value with encodeURIComponent so & becomes %26 and = becomes %3D. For example, a search value "a=b&c=d" must be encoded before adding it to ?q=. The safest pattern is to build URLs with URLSearchParams or your framework's URL builder instead of joining strings manually.

A path segment and a query parameter have different reserved characters. In a path, a slash separates segments, so a literal slash inside one segment should be encoded as %2F. In a query value, characters like &, =, and + can change parameter meaning, so encode the value with encodeURIComponent or URLSearchParams. Do not encode the entire URL at once unless you are sure it is already structured correctly. Build the URL piece by piece: base URL, path segments, then query parameters.

Yes. Emoji are Unicode characters, and URL encoding converts their UTF-8 bytes into percent-encoded sequences. For example, an emoji may become several %XX parts because it uses multiple bytes. In JavaScript, encodeURIComponent("") gives a safe URL component. When decoded correctly, it turns back into the same emoji. Problems happen when systems assume ASCII or decode using the wrong character encoding. For best results, keep everything UTF-8, use standard URL APIs, and test the full round trip through your browser, server, logs, and database.

When an email address is used as a query parameter value, encode it with encodeURIComponent. The @ becomes %40, and + becomes %2B. This matters because + is sometimes treated as a space in form-style query encoding. For example, user+test@example.com should not arrive as user test@example.com. If you use URLSearchParams, it handles this for you. Do not encode the entire mailto: URL blindly; encode the parameter values, such as subject or body, separately so the URL structure remains intact.

In a URL, ? starts the query string and # starts the fragment. If those characters are part of your actual data, they must be percent-encoded as %3F and %23. Otherwise, the browser treats everything after # as a fragment and may not send it to the server. This is common when passing redirect URLs, search text, document titles, or encoded JSON. The fix is to encode parameter values with encodeURIComponent or URLSearchParams before attaching them to the URL.

%2F decodes to / and %3F decodes to ?. Whether you should decode them depends on where they are used. Inside a query parameter value, decoding is usually fine. Inside a path, decoding %2F can change one path segment into two segments, which may affect routing or security checks. Many frameworks decode parts of the URL automatically, so avoid decoding twice. When debugging, decode one component at a time and keep track of whether you are working with the path, query, or fragment.

The hex digits in percent-encoded sequences are case-insensitive, so %2F and %2f represent the same byte. Many tools output uppercase hex because it is easier to read and common in specifications, but lowercase usually works too. The case of the decoded character may still matter, of course; %41 is "A" and %61 is "a". For consistency, let standard URL APIs produce the encoding instead of manually changing percent sequences. That keeps output predictable and avoids accidental edits to real text characters.

Put one URL or URL component per line, choose encode or decode, and run the batch action. Before encoding, decide whether each line is a full URL or only a component value. Full URLs should not always be encoded as one big string, because characters like :, /, ?, &, and # may be structural. For query values, encode each value separately. For decoding, watch for double-encoded text: decode once, inspect the result, and only decode again if you intentionally need to.