Base64URL encode

Three characters. This tool runs ordinary Base64 and then swaps plus for minus, slash for underscore, and strips the trailing equals padding. That leaves only A to Z, a to z, 0 to 9, minus and underscore, which are all safe in a URL path, a query string or a filename without any further escaping.

It is removed on purpose. Padding carries no information; a decoder can work out how many bytes the last group holds from the length alone. Stripping it is what the URL-safe form normally does, and it keeps the value out of trouble in query strings where an equals sign has its own meaning. Most decoders add the padding back for you.

Yes, the same alphabet. A JWT is three Base64URL chunks joined by dots: the header JSON, the payload JSON and the signature bytes. This tool encodes one chunk from one file. To go the other way and read a whole token, use JWT decode, which splits it and prints the header and payload as JSON.

No. The swap to a URL-safe alphabet is still a way of writing bytes as text. Anyone holding the string can read the original back, so treat a Base64URL token in a URL as visible to logs, browser history and anything sitting between you and the server.

Yes. Every character it can produce is unreserved in a URL, so nothing needs percent-encoding on top and the value survives a path segment, a query parameter or a filename unchanged. That is the difference from URL encode, which escapes reserved characters with percent signs and leaves ordinary letters alone. Encode the bytes here; escape the surrounding text there.

In your browser, in a Web Worker, on the file you dropped. Nothing is sent to a server, nothing is written to disk unless you download it, and nothing is kept once the tab closes. Drop a folder of files and each one is encoded separately, giving you one result block per file.