URL encode

It applies encodeURIComponent, which leaves letters, digits and the characters minus, underscore, period, exclamation mark, tilde, asterisk, apostrophe and parentheses alone, and percent-encodes everything else. That includes slash, question mark, hash, ampersand, equals and colon, all of which have a job inside a URL.

Always %20. The plus convention belongs to HTML form bodies sent as application/x-www-form-urlencoded, not to URL components, and this tool never produces it. If the system you are feeding expects plus signs, replace %20 yourself after encoding. Decoders that follow the URL rules read %20 correctly in both places.

You can, but it is rarely what you want. It encodes a component, so the slashes, colon and question mark of a full address all come back as percent escapes and the result is no longer a working link. Encode only the piece that goes inside a query parameter or a path segment.

They are written as their UTF-8 bytes, one percent escape per byte. So e-acute becomes %C3%A9, and an emoji becomes four escapes such as %F0%9F%98%80. That is the standard behaviour, and any URL decoder reassembles the characters. It also means a short piece of non-Latin text can expand several times over.

Different destination. URL encoding makes text safe inside an address using percent escapes; HTML entity encoding makes text safe inside a page using named entities such as <. Using one where the other belongs leaves the original problem in place.

No. The file is read and encoded in a Web Worker in this tab, so whatever you are escaping stays on your device. Query strings often contain search terms, tokens or customer identifiers, which is exactly the kind of text people paste into an online encoder without thinking. Here there is nothing to paste it into.