Drop any file — document, archive, audio, video, executable — and get its Base64 encoding. Supports files up to 50 MB and never leaves your browser.
Base64-encoding arbitrary files is useful when the destination only accepts text — embedding a binary blob in a JSON config, a YAML manifest, an email attachment, or a database column. Output size is ~133% of the original. For very large files, consider whether a separate file upload is more appropriate.
Any type — documents, archives, executables, audio, video, images, configuration files. The tool reads the raw bytes and encodes them; the file format does not matter. Up to 50 MB per file.
When the destination only accepts text — embedding a binary file in a JSON request body, YAML configuration, an email message, a database column, or a URL. Base64 lets binary data travel through text-only channels safely.
No. The encoding happens in JavaScript using the FileReader API. Your file is read into memory, encoded, and the result is displayed. We do not have a server-side endpoint for this tool.
About 33% larger — Base64 represents every 3 bytes of input as 4 ASCII characters. A 1 MB file becomes approximately 1.33 MB of Base64 text. Add a small overhead for line wrapping or a data URI prefix if applicable.
Base64 turns binary data into printable ASCII text — a useful property whenever you need binary data to traverse a text-only channel. The most common reasons developers reach for file-to-Base64 conversion: embedding files in JSON or YAML configuration, storing binary blobs in databases that only accept text columns, attaching files to email when traditional attachment headers are not available, passing binary data through environment variables or command-line arguments, and shipping reproducible test fixtures inside source code.
It is not the right tool for performance-sensitive transfers — Base64 inflates data by 33%, so a 10 MB file becomes 13.3 MB. For bulk transfers, dedicated binary protocols (gRPC, multipart form, raw POST with the right Content-Type) are always more efficient. Base64 wins when convenience and simplicity matter more than wire efficiency.
This tool supports four variants of Base64 output. Standard Base64 uses the original alphabet (A–Z, a–z, 0–9, +, /) with = padding — what RFC 4648 §4 defines and what most APIs expect by default. URL-safe Base64 replaces + with - and / with _ so the encoded string can appear in URLs and filenames without percent-encoding — RFC 4648 §5. URL-safe, no padding additionally drops the trailing = characters — common in JWT-style systems and in OAuth flows. MIME variant wraps output into 76-character lines, required by email MIME messages and some legacy parsers but unwanted in JSON or modern APIs.
When in doubt, use Standard Base64 — it is the universally accepted form. Only switch to URL-safe when the destination explicitly requires it (URL parameters, JWT tokens), and only use MIME wrapping when the destination is an email system or a tool that requires the line-wrapped form.
Configuration files (YAML, JSON, TOML). Tools like Kubernetes, Docker Compose, and Helm sometimes accept Base64-encoded binary content inside otherwise-text configuration. A common pattern: a secret manifest with a private key encoded as Base64 in the data field. Use Standard Base64 here.
Database columns. If you must store a binary file in a TEXT or VARCHAR column (often because your ORM does not handle BLOBs well), Base64 is the standard wrapper. Many ORMs have transparent Base64 columns that handle the encoding on write and decoding on read.
Email attachments. The MIME standard requires binary attachments to be Base64-encoded with 76-character line wrapping. Use the MIME variant. Email clients automatically decode on receipt.
Test fixtures in source code. Sometimes a test needs to verify behavior with a real binary input (a small PNG, a 1 KB PDF, a sample audio clip). Encoding the fixture as Base64 and embedding it as a string constant in the test file makes the test self-contained.
The 50 MB file size limit is a soft browser limit — JavaScript can encode larger files, but the tab will likely become unresponsive and the resulting Base64 string can crash some text editors. For files in the 50 MB to 1 GB range, use a command-line tool (base64 on macOS and Linux, certutil on Windows). For files larger than 1 GB, switch to chunked transfer or binary protocols entirely.
Memory usage during encoding is roughly 3× the file size — the original bytes, the Base64 string, and an intermediate buffer all coexist in memory. On low-memory devices, this can be the practical limit, not the file size.
If the encoded output appears in a different language (typically when serving content with the wrong Content-Type), browsers can interpret the Base64 string as URL-encoded text and apply unexpected transformations. To prevent this, always treat Base64 output as opaque — do not let it pass through URL encoders, HTML escapers, or other text-transforming layers.