| # | Hex | Dec | Char | Copy |
|---|---|---|---|---|
| {{ b.i }} | {{ b.hex }} | {{ b.dec }} | {{ b.ch }} | |
| No bytes | ||||
Base64 is a text alphabet for binary data. It exists for the awkward places where the real payload is bytes, but the channel only wants printable characters, such as API fields, tokens, email-safe bundles, and data URLs. This package helps you move between those two views without guessing where padding, URL-safe symbols, or text encoding changed the result.
The tool works in both directions. It can encode typed text or uploaded file bytes into Base64, and it can decode a pasted Base64 string back into text, a byte preview, or a data-URL payload. That dual view matters when the real question is not just "what does this decode to?" but "did the exact byte sequence survive the trip?"
A practical example is an API request that contains a Base64 field copied from a browser app, while the receiving service expects URL-safe characters and no trailing padding. Another common case is a MIME or PEM-style block that arrives with hard wraps and stray whitespace. The package lets you normalize those variants, inspect the byte table, and export the exact result instead of relying on a one-line converter that hides the failure mode.
The extra result views are there for inspection rather than decoration. The summary badges show mode, byte counts, URL-safe state, padding choice, line wrapping, and whether a Data URL wrapper is active. The byte table exposes index, hex, decimal, and printable-character previews, while the JSON tab records the active settings and byte totals in a structured payload.
The limit is conceptual, not mechanical. Base64 is reversible encoding, not encryption, hashing, or signing. If the original bytes were sensitive, they remain sensitive after encoding, and any system that receives the string can decode it again. The package does its work in the browser, which helps with local inspection, but copied text, downloaded files, and shared data URLs still deserve the same care as the original content.
Start by deciding whether the source of truth is text or bytes. If you are encoding prose, configuration fragments, or short identifiers, typing or pasting text is fine and UTF-8 is usually the safest default. If you are encoding a certificate, image, archive, or any other binary file, use the file picker or drag-and-drop path so the package reads raw bytes rather than a text editor's interpretation of them.
When decoding, the first decision is how forgiving normalization should be. Missing padding is common in URL contexts, so the padding-repair option is useful when the source omitted trailing = characters. Stripping non-Base64 characters is different: it is helpful for pasted MIME-like blocks with separators, but it can also hide a copy mistake. Use it when you know the surrounding noise is disposable, not as a routine cleanup habit.
The output interpretation setting matters only after bytes have already been recovered. If the decoded content is genuinely text, choosing UTF-8, UTF-16LE, Latin-1, or ASCII determines how those bytes are rendered back into characters. If the result is binary or suspicious, switch to raw bytes and let the byte table answer the question. That is usually the fastest way to distinguish "wrong text encoding" from "not text at all."
Variant settings should match the destination rather than personal preference. URL-safe mode changes the alphabet from +/ to -_. Padding can be kept or stripped. Wrapping can be disabled or set to MIME-style 76 columns or PEM-style 64 columns, with LF or CRLF line endings. Data URL mode adds a data:<mime>;base64, wrapper and is most useful when you are preparing a browser-consumable payload rather than a bare Base64 field.
The inspection tabs answer different questions. The primary output is for copy and download. Byte Breakdown is for exact verification, especially when text rendering looks wrong. The Data URL tab is for browser-embedded payloads. The JSON tab is for reproducible settings and size totals. If two systems disagree, start with the bytes tab and the settings summary before you assume the underlying content changed.
Base64 operates on bytes, not characters. The package therefore splits the work into two stages: first it turns the source into a byte array, then it renders or recovers Base64 from that array. In Encode mode, text input is converted with the chosen character encoding, while uploaded files bypass text conversion and go straight to raw bytes. In Decode mode, the tool normalizes the pasted input, decodes it to bytes, and only then decides whether to interpret those bytes as text or leave them as raw data.
The size relationship is fixed by the encoding scheme. Three bytes contain 24 bits, which map cleanly to four Base64 characters of 6 bits each. If the final byte group is shorter than three bytes, the standard padded form adds one or two = characters to keep the output on a four-character boundary. When the package strips padding, it removes those trailing fillers from the encoded text, but the underlying bytes remain the same.
The decode path adds several normalization steps before the actual byte conversion. Whitespace is ignored. URL-safe symbols are accepted by translating - and _ back to the standard alphabet. If Data URL syntax is present, the package strips the header and decodes the payload after the first comma. When padding repair is enabled, the tool appends the minimum number of = characters needed to restore a valid four-character block length. If stripping is disabled and any non-alphabet character remains, decoding stops with an explicit error instead of silently guessing.
The output views are generated from the recovered byte array and the active settings. The Byte Breakdown tab lists one row per byte with an index, hexadecimal form, decimal value, and printable-character preview. The JSON tab stores input settings, byte totals, Base64 lengths, and a preview of the active result. Export behavior follows the current surface: the main output downloads as text or binary, the byte table can be copied or saved as CSV and DOCX, the Data URL can be copied directly, and the JSON payload downloads as a structured record.
| Setting or state | Package behavior | Why it matters |
|---|---|---|
URL-safe |
Encode swaps +/ for -_; decode accepts either alphabet |
Prevents false mismatches between web-token and standard Base64 variants |
Include padding |
Encode keeps or strips trailing = |
Matches systems that require canonical padded form or omit padding entirely |
Fix missing padding |
Decode appends the minimum required = characters |
Recovers common pasted payloads that were shortened for transport |
Strip non-Base64 |
Optionally removes characters outside the Base64 alphabet | Useful for noisy pasted blocks, but it can also hide copy mistakes |
Wrap columns |
Applies no wrap, MIME 76, PEM 64, or a custom line width | Keeps output compatible with line-oriented formats |
Data URL |
Wraps encoded output as data:<mime>;base64,<payload> |
Supports browser embedding and quick inspection of small assets |
| Surface | What it shows | Exports available |
|---|---|---|
| Primary output | Encoded Base64, decoded text, or raw-byte preview depending on mode | Clipboard copy and direct download |
| Byte Breakdown | Index, hex, decimal, and printable preview for every byte | CSV copy, CSV download, and DOCX export |
| Data URL | Browser-embeddable data URL form for encoded output | Clipboard copy and download through primary output |
| JSON | Inputs, totals, and structured result preview | Clipboard copy and JSON download |
Encode when the source is text or file bytes you want to represent as Base64, or choose Decode when the source is a Base64 string you want to inspect.The summary counts are most useful as a sanity check. Input bytes tell you how much raw content the package received. Output bytes tell you what the decode path recovered or what the encode path started from. If the encoded length looks surprising, check padding and line wrapping before you assume the bytes changed.
The byte table is the authoritative view when text rendering is ambiguous. A readable decoded string means the recovered bytes fit the selected output encoding. Replacement characters or odd symbols usually mean the bytes are real but the chosen text interpretation is wrong. A mostly non-printable preview usually means the payload is binary and should be handled as bytes rather than text.
Errors should be read literally. Found non-Base64 characters means the input still contains disallowed characters after optional cleanup rules. Invalid Base64 content. means the cleaned input still cannot be decoded into a valid byte sequence. In both cases, compare the pasted value and the selected cleanup settings before you trust any downstream system.
A service accepts an unpadded URL-safe token, while another tool shows the same value with trailing =. Encode or decode the payload with and without padding enabled, then compare the Byte Breakdown rows. If the byte table is identical, the difference is only textual form, not content.
You receive a Base64 block copied from an email-style document with line breaks every 76 characters. Paste it in Decode mode, leave whitespace handling alone, and inspect the recovered output. If extra separators or commentary were pasted too, enable Strip non-Base64 only after confirming the noise is supposed to be ignored.
Upload a small image in Encode mode, let the MIME type autofill from the file, and enable Data URL output. The main result becomes a browser-ready data: string, while the JSON tab records the MIME type, byte totals, and output preview so the exact settings can be reused later.
No. It only changes binary data into a text alphabet. Anyone with the encoded string can decode it back to bytes.
The recovered bytes may be correct, but the selected output encoding may not match them. Try another text interpretation or inspect the raw bytes directly.
It helps when the pasted block includes separators or surrounding formatting, but it should be used deliberately because it can also hide a copying mistake.
The main output is for direct reuse. Byte Breakdown is for validation, because it shows the exact recovered bytes row by row.
= characters used in standard Base64 to keep the encoded output aligned to four-character blocks.+ and / with - and _ so the string is safer to place in URLs.data:<mime>;base64,<payload>.