File to Base64 without freezing the tab

Because File.type is not read from the file — it is looked up from the extension in the operating system's registry, and that registry can be empty, stale or hijacked. Chrome commonly reports nothing at all for .svg, .md, .yaml and .toml; Windows reports text/csv as application/vnd.ms-excel once Excel claims the extension; and a file renamed from .jpg to .png is reported as a PNG that no decoder will accept. This page reads the first 4 KB and matches it against known signatures, so the bytes settle any argument, and it tells you when there was one.

Not here, because the work is split. Reading a 5 MB file into one buffer and encoding it in a single pass blocks the main thread for the whole duration, and the tab stops painting — no scroll, no cursor, no progress. This page slices the file at 768 KB, encodes one slice, yields to the event loop, then takes the next, so the longest uninterrupted block of work is a fraction of the total. The slice size is a multiple of 3 on purpose: Base64 works in 3-byte groups, and cutting anywhere else would give each half its own padding and produce a string that decodes to rubbish.

Whenever the payload is large, changes often, or has to cross a boundary that limits length. Past about 30 KB inlining costs more than the request it saves, and the panel says so outright. A cookie is capped at 4,096 bytes by RFC 6265, so anything bigger simply will not be stored. A URL runs into nginx's 8 KB buffer for the request line and headers and comes back as a 414. HTML email is worse than either — Outlook on Windows and Gmail on the web both strip data: image sources, so an inlined logo arrives as an empty box.

The page works it out for your actual file and tells you. RFC 6265 §6.1 only requires a browser to support 4,096 bytes per cookie including the name, so the practical ceiling for a Base64 value is around 4 KB — about 3 KB of original file. For a URL the binding limit is usually the server rather than the browser: nginx allows 8 KB for the request line and all headers together by default, and exceeding it returns 414 or 400 rather than a useful error. Both checks appear under the output with a yes or no.

Yes, and this page will say so. Every Office Open XML document — .docx, .xlsx, .pptx — is a ZIP archive whose first four bytes are 50 4B 03 04, with the real content in XML files inside it. So is an .epub, and so is a .jar. Signature matching alone would call all of them archives, so the encoder looks a little further and reads the first member names: a word/ directory makes it a Word document, xl/ an Excel workbook, META-INF/container.xml an EPUB. That is the same trick the file command uses, and it is why the media type here is more specific than application/zip.

Because a JavaScript string is UTF-16, two bytes per character, whatever those characters are. Base64 is pure ASCII, so every character costs a byte it does not need: a 5 MB file becomes 6,990,508 characters, and holding those characters costs about 13.3 MB of memory while the original bytes are still around too. That is the real reason a browser-based encoder has a size ceiling — not the arithmetic, which is fast, but the several copies of the payload alive at once.

One file at a time, deliberately. A batch of Base64 strings has to be labelled and separated somehow, every tool invents its own format for doing that, and none of them is what the next tool expects — so the output stops being useful the moment it leaves the page. If you need a folder as one payload, zip it first and encode the archive: the ZIP keeps the names and the structure, and the Base64 stays a single string with one obvious meaning.