Image to Base64 is the conversion of an image’s binary file bytes into Base64 text so the encoded image can be stored in a text field or embedded where a text representation is required.
Base64 is a reversible text encoding, not encryption or compression. It trades binary size for a longer string using a restricted character set, which makes an image convenient for JSON, code fixtures, and some application payloads. It is usually a poor substitute for an ordinary image file or URL in normal website delivery.
What the image-to-Base64 process actually does
Image-to-Base64 conversion treats the file as a sequence of bytes. It groups those bytes and replaces each group with characters from a fixed alphabet. The result is a reversible representation of the same file bytes, not a new image and not a compressed copy.
The output follows the canonical alphabet and padding rules in RFC 4648. Uppercase and lowercase letters, digits, plus, and slash carry the encoded data, while one or two terminal equals signs pad the final group when it contains fewer than three bytes.
- The payload contains the selected file’s bytes, not its original filename.
- Base64 changes how the bytes are written without changing their contents.
- Decoding a valid payload can reproduce the exact original file bytes.
The key distinction is encoding versus transformation. Base64 cannot make a low-resolution image sharper, reduce its file size, repair damage, or conceal the image’s contents.
Plain Base64 and data URLs are different outputs
Plain Base64 and an image data URL carry the same encoded payload, but they serve different interfaces. The required output depends on what the receiving system expects.
| Feature | Plain Base64 | Image data URL |
|---|---|---|
| Output beginning | Base64 characters and padding only | A MIME prefix, comma, and the same Base64 payload |
| MIME handling | No MIME type is included | The MIME type comes from verified bytes, such as data:image/png;base64, |
| Typical destination | An API, JSON fixture, or test that expects only the payload | An HTML or CSS experiment or another destination that expects a complete image URI |
| What to copy | Canonical Base64 characters and terminal padding | The entire prefix and complete canonical payload |
Choose plain mode when the receiver asks only for the encoded value. Choose data URL mode when it expects a complete image source. A valid PNG renamed photo.jpg still produces data:image/png;base64, because the verified bytes—not the filename—determine the MIME type.
Keep the prefix when the destination requires a data URL. Remove it only when the receiving format explicitly asks for raw Base64 rather than a complete URI.
Why the filename does not decide the format
A reliable converter must distinguish a complete image container from a renamed, damaged, or truncated file. The Image to Base64 Converter ignores the filename extension, file-picker filter, and operating-system MIME string when selecting the output format. It inspects the actual bytes instead.
- PNG: Requires the complete eight-byte signature, a correctly shaped first IHDR chunk, and a terminal IEND boundary.
- JPEG: Must begin with an SOI marker and a following marker and end with EOI.
- GIF: Must contain a GIF87a or GIF89a header, enough bytes for its logical screen descriptor, and a terminal trailer.
- WebP: Must have a RIFF length matching the file, the WEBP FourCC, and a bounded VP8, VP8L, or VP8X first chunk, as defined in the WebP RIFF container specification.
Supported means these four complete byte containers only. SVG, AVIF, HEIC, BMP, TIFF, PDF, and arbitrary text are outside scope, even when a browser or file extension calls them images. A dedicated converter is required for another format.
Structural preflight is followed by real browser decoding. The browser must decode the image and report positive dimensions before a result appears, so a few matching header bytes cannot create an apparently successful output. See the byte-based image format detection guide for more detail on this validation approach.
Convert a local image in a verified workflow
- Open the Image to Base64 Converter, choose one local PNG, JPEG, GIF, or WebP file, and select either plain Base64 or an image data URL as the output.
- Run the conversion. The tool checks the browser-reported file size, reads the file, verifies its container structure, and asks the browser to decode it using the detected MIME type.
- Confirm the detected byte format, real decoded dimensions, source file size, and preview before using the result.
- Copy the complete output. In data URL mode, include the full MIME prefix because it comes from the verified image bytes. If clipboard access is denied, the visible output remains available for manual selection and copying.
- Paste the copied text into the intended API field, JSON fixture, HTML or CSS experiment, or other text-based destination, then test it in the receiving system.
File reading, container detection, browser decoding, Base64 encoding, preview creation, and copying all happen in the current browser tab. The image is not uploaded to Lizely or sent to an external conversion service.
Limits that decide whether conversion succeeds
The input limit is exactly 5 MiB, or 5,242,880 bytes. A file of exactly that size is accepted, while one byte beyond it is rejected before the file body is read when the browser reports its size. The actual ArrayBuffer length is checked again after reading, preventing a reported size from bypassing the boundary.
Worked size calculation: 5,242,880 ÷ 3 = 1,747,626 remainder 2, so the full encoding needs 1,747,627 groups. At four characters per group, 1,747,627 × 4 = 6,990,508 characters. The longest supported data URL prefix is 23 characters, so 6,990,508 + 23 = 6,990,531 characters.
| Check | Exact accepted limit | Beyond the limit |
|---|---|---|
| Input file size | 5,242,880 bytes | Rejected |
| Decoded image edge | 20,000 pixels per edge | Rejected |
| Decoded total area | 40,000,000 pixels | Rejected |
| Plain Base64 output | 6,990,508 characters | Rejected |
| Complete data URL output | 6,990,531 characters | Rejected |
After decoding, neither edge may exceed 20,000 pixels and the total area may not exceed 40,000,000 pixels. Exact boundary values are accepted. These limits matter because a compressed file can require much more memory after decoding than its file size suggests.
Nothing is silently capped. Errors distinguish missing or empty input, excessive bytes, incomplete or unsupported containers, browser decode failure, invalid dimensions, excessive decoded dimensions, and excessive output length. An oversized file produces an explicit error with no partial result. Changing the file or output format clears the previous preview, output, error, busy state, and copy status, while a late read from an older file cannot overwrite a newer selection.
What the Base64 payload preserves
Conversion preserves the original file bytes exactly. It does not draw the image onto a canvas, resize it, recompress it, recolor it, flatten transparency, select one frame from an animated GIF, remove metadata, repair damage, or optimize its size. Animated GIF and WebP bytes remain animated when the consuming software supports them.
The on-screen preview may be constrained to fit the page layout, but that display constraint does not alter the encoded payload. Treat every unknown image as untrusted content: successful decoding confirms technical readability, not authorship, truthfulness, accessibility, copyright status, moderation safety, or freedom from concealed data.
When a text representation is the right choice
Base64 is most useful when the destination specifically expects text, including API payloads, JSON fixtures, HTML and CSS experiments, email templates, offline prototypes, test data, and debugging workflows.
- For smaller output, compress the original in a separate step before encoding.
- For new dimensions, resize the image separately so every change to the bytes remains clear.
- For normal website delivery, use an ordinary image file or URL because Base64 adds roughly one-third before the data URL prefix.
If the workflow starts with a Base64 string and needs a viewable file or attachment, use the Base64 to Image guide for recovering an email attachment instead of encoding the file again.