Text to Binary & Base64

Understanding Binary Data & Base64 Representation

When developers build applications, store data structures, or communicate across network frameworks, they deal with various data formatting configurations. Converting between plain characters (text), base-2 binary bytes (octets), and base-64 text blocks is a fundamental process in developer workflows.

How Encoding & Decoding Works

Why Browser-Based Conversion is Safer

Step-by-Step: How to Use the Four Conversion Modes

The toolbar above the input and output panels exposes four distinct modes, and switching between them relabels the input/output panels and clears both boxes so you always know exactly which direction you're converting:

1. Text to Base64 — type or paste plain text on the left, and the Base64-encoded string appears instantly on the right as you type. This is the mode to use when you need to embed data inside JSON, XML, a URL query parameter, or a data URI.
2. Base64 to Text — paste a Base64 string (for example, a JWT segment, an API response field, or an encoded config value) and the decoded plain text appears on the right. If the string isn't valid Base64, the output panel reports "Invalid Base64 string!" instead of silently showing garbage.
3. Text to Binary — converts each character of your input into a space-separated sequence of binary digits, useful for teaching computer-science fundamentals or inspecting exactly how a short string is represented at the bit level.
4. Binary to Text — paste space-separated binary octets (like 01001000 01000101 01001100 01001100 01001111) and get the reconstructed text back. Each token must be valid binary (only 0s and 1s, 1–8 bits per token, since each token represents one UTF-8 byte); anything else triggers an "Invalid Binary string!" message rather than a wrong answer.

Every mode also supports three convenience actions: Import File reads a local .txt, .json, or .md file straight into the input box (you can also drag a file onto the input panel — a purple overlay confirms the drop zone is active), Copy Output puts the result on your clipboard in one click, and Download File saves the output as a timestamped .txt file. The character, byte, and bit counters below each textarea update live and are computed with Blob byte-size measurements, so the "Bytes" figure reflects real UTF-8 byte length rather than just the JavaScript string's character count — useful for confirming exactly how much a piece of text will actually weigh once transmitted or stored.

Exactly What This Converter Supports (and What It Doesn't)

To be precise about capabilities: this tool converts between plain text, Base64, and binary (bit-string) representations. It does not currently offer a hexadecimal conversion mode — if your workflow needs text-to-hex or hex-to-binary specifically, you'll want a dedicated hex converter instead. Within its four supported modes, here is exactly how faithfully each one round-trips real-world text:

In short: both the Base64 and Binary modes are fully UTF-8 safe. Base64 achieves this because the encoder deliberately runs text through encodeURIComponent/decodeURIComponent before and after the Base64 step — this is the standard, well-known trick for making JavaScript's native btoa/atob (which technically only understand single-byte Latin-1 characters) safe for arbitrary Unicode. The Binary mode gets there more directly, using the browser's built-in TextEncoder/TextDecoder to convert text to and from its real UTF-8 byte sequence before rendering each byte as 8-bit binary. That means the binary strings this mode produces are textbook-accurate UTF-8 byte binary — every chunk is exactly 8 bits, and any character outside the ASCII range simply produces multiple 8-bit chunks, exactly as a strict byte-level UTF-8 encoder would.

Real-World Use Cases

Common Mistakes & Gotchas

• Pasting URL-safe Base64 into the standard decoder. If a string uses - and _ instead of + and / (common in JWTs and URL parameters), swap those characters back before pasting, or the decoder will report an invalid string.
• Missing or extra padding characters. Standard Base64 strings should have a length that's a multiple of 4 once padding = characters are included — a truncated copy-paste is one of the most common causes of a failed decode.
• Malformed spacing in Binary mode. The Binary-to-Text decoder expects each byte separated by whitespace; pasting one long unbroken string of 0s and 1s without spaces will be read as a single (invalid) token rather than multiple bytes.
• Expecting hex output. Since there is no hex mode, don't paste a hexadecimal string (like 48656C6C6F) into either converter expecting it to be recognized automatically — it needs to be plain text, Base64, or space-separated binary.
• Assuming Base64 is encryption. Base64 provides zero confidentiality — anyone can decode it instantly. Never rely on it to "hide" secrets; use real encryption for that.

Why Base64 Adds Roughly 33% Overhead

The size increase isn't an implementation quirk — it's a direct consequence of the math behind the encoding. Base64 represents every 3 raw bytes (24 bits) using 4 output characters (4 × 6 bits = 24 bits), so the output is always 4/3 the length of the input before padding, which works out to a 33.3% size increase. A 300 KB file becomes roughly 400 KB once Base64-encoded. This matters in practice whenever you're deciding whether to embed a Base64 string directly (in a data URI, a JSON field, or an email attachment using MIME) versus linking to a raw binary file — the convenience of inlining data comes at a real bandwidth and storage cost, which is why Base64 is generally reserved for small assets (icons, short tokens, small config blobs) rather than large media files.

Padding characters (=) exist purely to keep the output length a clean multiple of 4 when the input isn't evenly divisible by 3 bytes: one trailing = means the last group had 2 input bytes, and two trailing == means the last group had only 1 input byte. Some contexts (URL query strings, filenames, and Base64Url as used in JWTs) strip padding entirely and swap +// for -/_ because those two characters have reserved meaning in URLs — that's exactly the transformation described in the FAQ below for building URL-safe Base64 by hand from this tool's output.

This Tool vs. Command-Line & Language-Native Alternatives

Every mainstream programming environment ships its own Base64 utilities — the base64 command on Linux/macOS, Python's base64 module, Node's Buffer.from(str).toString('base64'), and PowerShell's [Convert]::ToBase64String. Those are the right choice when Base64 conversion is one step inside an automated script or pipeline. This browser-based tool fills a different, complementary need: a zero-install way to eyeball a single value during debugging, without opening a terminal, without worrying about shell-escaping special characters, and without installing a runtime just to decode one string someone pasted into a support ticket or a Slack message. Because the underlying algorithm (RFC 4648) is a public standard, output produced by any of those command-line tools will decode correctly here, and vice versa — there is no proprietary variation in how the Base64 alphabet or padding rules are applied.

Where Base64 Came From — and Where You'll Still Find It

Base64 wasn't designed for the web at all — it originates from MIME (Multipurpose Internet Mail Extensions), the 1990s standard that made it possible to send images, attachments, and non-English text over email systems that were originally built to carry only 7-bit ASCII. By re-encoding arbitrary binary data as a restricted set of 64 printable ASCII characters, MIME guaranteed an attachment would survive being routed through mail servers that might otherwise mangle high-bit or control characters. That same "make binary data safe for a text-only channel" idea is why Base64 quietly shows up everywhere in modern software decades later: HTTP Basic Authentication headers, embedded image data URIs in CSS and HTML, the header and payload segments of JSON Web Tokens, binary attachments in JSON APIs, encoded certificates in PEM files, and configuration values in Docker and Kubernetes secrets. Understanding Base64 is less about one specific format and more about recognizing this one recurring pattern across nearly every layer of the web stack.

Privacy & Data Handling

Every conversion in this tool — Base64 encode/decode, binary encode/decode, and file import/export — is handled entirely by JavaScript running in your browser tab using built-in browser APIs (btoa, atob, FileReader, Blob). There is no fetch or XHR call anywhere in the conversion logic, meaning the text, credentials, tokens, or files you paste or upload are never transmitted to any server, logged, or stored remotely. Uploaded files are read locally via the browser's File API and immediately discarded from memory when you navigate away or refresh the page; nothing persists beyond your current tab session. This makes the tool safe to use even with sensitive values — API keys, session tokens, internal config snippets — that you would not want to paste into a random third-party web service of unknown provenance.