Base64 encode decode

Base64 is a binary-to-text encoding scheme that represents arbitrary bytes using 64 printable ASCII characters: the letters A–Z, the lowercase letters a–z, the digits 0–9, plus + and /, with = used as padding at the end. It exists because a lot of the infrastructure the internet is built on — email, JSON payloads, URLs, older text-only protocols, XML documents — was designed to carry human-readable text safely, but can mangle, truncate, or misinterpret raw binary bytes. Encoding that binary data as Base64 turns it into plain, printable text that survives being copied, pasted, stored in a database column, or transmitted through systems that were never built to handle arbitrary bytes.

The mechanism is simple: the encoder takes the input three bytes (24 bits) at a time and repacks those 24 bits into four 6-bit groups, each of which maps to one of the 64 characters in the Base64 alphabet. That is also why an encoded string ends up roughly 33% larger than the original data — you are trading some size for universal, lossless text-safety. For a password, a JSON Web Token fragment, a small image icon, or a config value, that tradeoff is essentially free; for large files it starts to matter, which is why Base64 is normally reserved for smaller payloads rather than entire video files.

It is worth being precise about what Base64 actually is, because the name causes confusion: it is not a compression algorithm (it makes data larger, not smaller), it is not a hashing algorithm (it is fully reversible, not one-way), and — the most common misconception — it is not an encryption algorithm. It is purely a representation change: the same bytes, described using a different, text-safe alphabet.

One of the most visible uses of Base64 on the modern web is the data URI, a way of embedding a file directly inside HTML, CSS, or JSON instead of linking to a separate file on a server. A data URI looks like data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA... — the MIME type tells the browser what kind of file it is, and everything after base64, is the file's raw bytes encoded as text.

Data URIs are handy for small, frequently-reused assets: a favicon, a tiny logo, an inline SVG icon, or a background pattern. Embedding them inline saves the browser an extra HTTP request, which can matter for performance on pages with dozens of tiny icons. The tradeoff is the same 33% size increase mentioned above, plus the fact that inlined assets can no longer be cached separately by the browser — so data URIs make the most sense for small, rarely-changing files, not large photos or fonts that benefit from independent caching.

The File → data URI button in the tool above does exactly this conversion: pick any file from your device and the tool reads it locally with the browser's FileReader API, producing a ready-to-paste data URI you can drop straight into a stylesheet, an <img> tag, or a JSON config — all without the file ever touching a server.

• Data URIs — embedding a small image, font, or icon directly inside HTML or CSS with data:image/png;base64,... instead of a separate file request, as described above.
• Email attachments — MIME messages encode binary attachments (PDFs, images, spreadsheets) as Base64 so they can travel safely over text-based SMTP, which was originally designed only for ASCII text.
• JWT parts — JSON Web Tokens encode their header and payload segments with Base64URL (a URL-safe variant that swaps +// for -/_ and usually drops padding) before the whole token is signed. If you have ever pasted a JWT into a debugger and seen three dot-separated chunks of gibberish, the first two are Base64URL-encoded JSON.
• APIs and config files — passing binary data such as images, certificates, encryption keys, or credentials through JSON, YAML, or XML, all of which only support text values and have no native way to embed raw bytes.
• Basic authentication headers — HTTP Basic Auth sends username:password as a Base64-encoded string in the Authorization header, in the form Authorization: Basic dXNlcjpwYXNz.
• Source maps and inline scripts — some build tools embed source maps or small binary blobs as Base64 directly inside a JavaScript bundle to avoid an extra network round trip.
• Certificates and keys — PEM-formatted TLS certificates and SSH keys are Base64-encoded DER data wrapped between header and footer lines, which is why they are readable as plain text files.

1. Choose a mode. Click Encode to turn plain text into Base64, or Decode to turn a Base64 string back into readable text.
2. Type, paste, or upload. Type or paste directly into the left box and the result updates live in the right box, or click Upload file to load the contents of a .txt, .json, or .csv file straight into the input using your browser's FileReader.
3. Copy or download the result. Use Copy result to copy the output to your clipboard, or Download to save it as a .txt file for later.
4. Swap to round-trip. Use Swap to move the current result into the input box and flip the mode, which is a quick way to verify an encode/decode pair matches.
5. Convert a file to a data URI. Use File → data URI to turn an image or other file into a paste-ready Base64 data URI for HTML or CSS.
6. Clear when you're done. Use Clear to reset both boxes and start fresh.

Because everything runs locally in your browser tab, there is no file size cap enforced by a server, no rate limit, and no account required — you can encode and decode as many times as you like.

This is the single most common misunderstanding about Base64, and it is worth repeating clearly: encoding a string does not protect it. Base64 is fully reversible with no key, no password, and no secret of any kind — anyone can decode it in one line of code, with a browser extension, or with this same tool. There is no computational cost to reversing it, unlike a hash or an encrypted ciphertext.

A surprising number of real systems have shipped bugs because someone treated Base64 as if it were security. Storing a password "encoded" as Base64 in a database, or slipping an API key into a URL as a Base64 string and assuming it is hidden, both provide precisely zero protection — anyone who can see the string can read the original value instantly. Basic Authentication headers are a good real-world cautionary example: the credentials are Base64-encoded purely so they survive the HTTP header format, not to keep them secret, which is exactly why Basic Auth is only considered safe over HTTPS.

If you need actual confidentiality, reach for real encryption — symmetric ciphers like AES for data at rest, TLS for data in transit, or a dedicated secrets manager for credentials — and reserve Base64 for what it is genuinely good at: making binary data safe to carry inside text-only formats. Encoding and encryption solve different problems, and conflating them is how sensitive data ends up exposed in logs, URLs, or version control history.

• Watch out for URL-unsafe characters. Standard Base64 uses + and /, both of which have special meaning in URLs. If you are putting an encoded value in a query string, use the Base64URL variant instead, which replaces those characters with - and _.
• Don't forget padding. The trailing = characters pad the string to a multiple of four; stripping them (common in some JWT implementations) is fine as long as the decoder knows to re-add them before decoding.
• Multi-byte text needs UTF-8-aware encoding. A naive btoa() call in JavaScript throws on non-Latin1 characters like emoji or most non-English scripts. This tool converts text to UTF-8 bytes first, so accented letters, CJK text, and emoji all round-trip correctly.
• Whitespace breaks decoding. A Base64 string copied from an email client or a PDF often picks up stray line breaks or extra spaces. Trim the string before decoding, or use a tool (like this one) that trims it for you.
• Large files add up fast. Remember the ~33% size increase — embedding a multi-megabyte file as a data URI or JSON string can bloat a page or payload noticeably. For large binaries, prefer sending the raw file (e.g. multipart form upload, object storage) over Base64-encoding it inline.
• It is deterministic. The same input always produces the same Base64 output, which makes it useful for generating stable cache keys or comparing binary blobs as text — but also means it offers no protection against dictionary or lookup-table attacks if misused as if it were a hash.

• Web developers inline small icons and fonts as data URIs, debug JWT payloads, and troubleshoot Basic Auth headers during API integration work.
• Backend and API engineers pass binary blobs — images, PDFs, certificates — through JSON request bodies and config files that only accept text values.
• DevOps and platform engineers decode Kubernetes secrets, environment variables, and CI/CD pipeline variables, which are frequently stored Base64-encoded.
• Security researchers decode suspicious strings found in malware samples, phishing emails, or obfuscated scripts, where Base64 is a common (and weak) obfuscation layer.
• Students and self-taught developers use it to understand how encoding, JWTs, and MIME email attachments actually work under the hood.
• Support and QA teams quickly decode a Base64 string from a bug report or log file without opening a terminal or writing a script.

Yes. Every operation — encoding, decoding, file upload, data-URI conversion, and download — runs entirely inside your browser tab using the built-in TextEncoder, TextDecoder, and FileReader APIs. Nothing you type or upload is sent to a server, logged, or stored anywhere. That makes it safe to use for API keys, tokens, credentials, or any other sensitive text you need to encode or decode, and it also means the tool keeps working if you lose your internet connection after the page has loaded.