URL encoder

The same string, three encodings

Take hello world/foo?x=1. Component encoding is hello%20world%2Ffoo%3Fx%3D1, because a space, a slash, a question mark, and an equals sign would otherwise be URL syntax. Form-body encoding is hello+world%2Ffoo%3Fx%3D1: the same reserved characters, but a space becomes a plus. encodeURI for a complete URL is hello%20world/foo?x=1, because it leaves the delimiters in place. Paste that string here and the three rows should match those three strings.

Which encoding, by destination

A query value and a path segment want component encoding, where a space is %20. A form body wants application/x-www-form-urlencoded, where a space is +. A fragment is a component too. A complete URL that already has its delimiters in place wants encodeURI, which leaves : / ? # & = alone so the URL keeps working.

The plus sign, which is why you are here

There are two percent-encodings in daily use. They are not identical except for a space. On ~_.-!*() a, component encoding is ~_.-!*()%20a and form encoding is %7E_.-%21*%28%29+a. They differ for ~, !, (, ) and the space.

Component encoding is what encodeURIComponent produces. A space becomes %20. RFC 3986 section 2.3 names letters, digits, -, ., _ and ~ as unreserved; encodeURIComponent also leaves !, *, (, ) and ' literal, which that unreserved set does not. Use it for a single value going into a path segment, a query value or a fragment.

Form encoding is the application/x-www-form-urlencoded serializer, which is what an HTML form posts and what most server frameworks assume when they parse a query string. A space becomes +.

Encode one way, decode the other, and a space turns into a literal plus or a genuine plus turns into a space. That second one is the expensive version: a plus in an email address, a signature or a base64 string is meaningful, and turning it into a space corrupts the value rather than merely looking odd. The decode result row is decodeURIComponent, the widest of the three going backwards, and Copy first result copies that row. Encode-mode rows name encodings. Decode is not an encoding, so its set name is -. Raising the pass ceiling changes how many times decode runs, not the label. If the input contains a plus, both readings are printed beside it, labeled form data and RFC 3986, and neither of those labels is marked as chosen.

The third one, and when not to use it

encodeURI is for a complete URL, and it deliberately leaves : / ? # & = alone so the URL keeps working. That makes it exactly wrong for encoding one value: a value containing an ampersand or an equals sign will pass through untouched and then be read as a parameter boundary by the receiving server.

It is shown here because it is genuinely the right answer when the whole thing you are holding is a URL with a space in it. The set name beside that row says it matches no WHATWG encode set, because naming the nearest set would be a claim the row does not keep.

Hosts are not percent-encoding

A non-ASCII host is IDNA-encoded, not percent-encoded. Mixing the two is how a host gets percent-encoded when it should not. When the input parses as a URL, the parts table shows the host in the IDNA form the WHATWG parser produces, and says so beside that cell. The three encode rows still percent-encode the whole string, including the host, because that is what those three functions do.

Decoding a string that was encoded twice

When the decoded result is itself a URL, this breaks it into scheme, userinfo, host, port, path, query and fragment. Recursive decode sets a ceiling of 1 to 16 passes and then reports how many passes actually changed the string. If the input already contains a percent-escape, decode mode says so before you have to notice leftover percent signs.

One thing the parts table quietly demonstrates: the fragment, the piece after the #, is the only part of a URL a browser never sends to a server. That is why every tool on this site puts shareable state there.

What this deliberately does not do

It does not wrap output into 76-character lines. That wrapping is an RFC 2045 MIME convention, and a wrapped percent-encoded URL is not a URL. It does not take a file; per-line encode and decode cover the bulk job. It does not convert a host to punycode as its own product, and it does not do base64 or hex. Those are a different row.

The three named rows are UTF-8. There is no charset control on this page. Bytes in another charset belong with the fourth row, which is out of this version.

Questions

Related tools

For = padding rather than % escapes, you want base64. If the decoded value turns out to be JSON, the JSON formatter will indent it and locate any syntax error, and the tool chain will do both steps on one paste.