Skip to content
Lizely

Image to Base64 Converter

Convert a validated PNG, JPEG, GIF, or WebP file to plain Base64 or an accurate image data URL without uploading it.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Choose one PNG, JPEG, GIF, or WebP file and select plain Base64 or an image data URL.
  2. 2.Convert the file and confirm the detected byte format, real decoded dimensions, file size, and preview.
  3. 3.Copy the complete output, whose data URL MIME comes from the verified image bytes when that mode is selected.

About Image to Base64 Converter

Image to Base64 converts a local PNG, JPEG, GIF, or WebP file into standard RFC 4648 Base64 entirely in your browser. Choose an image, select plain Base64 or a complete data URL, run the conversion, inspect the validated preview, and copy the exact text output. The file is not uploaded to Lizely or sent to an external conversion service. This makes the tool useful for API payloads, JSON fixtures, HTML or CSS experiments, email templates, offline prototypes, test data, and debugging workflows where an existing image must be represented as text. The converter does not trust the filename extension, the file picker accept filter, or the MIME string supplied by the operating system. Those values are convenient hints and can be missing, stale, or intentionally misleading. Instead, the same pure structural detector used by the paired Base64 to Image tool inspects the actual bytes. PNG must have the complete eight-byte signature, a correctly shaped first IHDR chunk, and a terminal IEND boundary. JPEG must begin with SOI 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 that exactly matches the file, the WEBP FourCC, and a bounded VP8, VP8L, or VP8X first chunk. Bare magic bytes and truncated containers are rejected. Structural preflight is intentionally followed by real browser image decoding. The browser must decode the Blob and report positive dimensions before any result is shown. A corrupt payload that resembles a known header therefore cannot produce an apparently successful output merely because its first bytes match. The detected byte format determines the MIME in data URL mode. A PNG renamed photo.jpg or declared image/jpeg still produces data:image/png;base64, followed by the payload. Plain mode returns only the canonical Base64 characters and padding. Encoding follows the RFC 4648 alphabet with uppercase letters, lowercase letters, digits, plus, and slash, and writes one or two terminal equals signs when the last group contains fewer than three bytes. The manual encoder works in bounded byte chunks aligned to three-byte groups. It never spreads the complete byte array into String.fromCharCode or a similar variadic call, so a multi-megabyte image does not overflow the JavaScript call stack. Joining chunks changes only how the result is constructed; it does not sample, shorten, wrap, or otherwise alter the encoded bytes. Published RFC 4648 vectors verify the grouping and padding cases. Complete fixtures for all four image formats verify exact known output, accurate data URL MIME, and byte-for-byte round trips through the strict decoder shared with the inverse tool. The input limit is exactly 5 MiB, equal to 5,242,880 bytes. The exact boundary is accepted and one byte beyond is rejected before the file body is read when the browser reports its size. The actual ArrayBuffer length is checked again after reading. The maximum Base64 length for that byte budget is 6,990,508 characters. The output budget includes the longest supported data URL prefix and accepts exactly 6,990,531 characters while rejecting the next character. Nothing is silently capped. An oversized file produces an explicit error and no partial result. After decoding, neither image edge may exceed 20,000 pixels and total area may not exceed 40,000,000 pixels. These limits matter because a compressed image can occupy much more memory after decoding than its file size suggests. Exact limits are accepted; an excess edge or pixel-area pair is rejected. Conversion preserves the original image bytes inside the Base64 payload. It does not draw onto canvas, resize, recompress, recolor, flatten transparency, select a GIF frame, remove metadata, repair damage, or optimize file size. Animated GIF and WebP bytes remain animated when a consumer supports them. The constrained preview affects only page layout. Base64 itself increases transport size by roughly one third before a data URL prefix and should not replace ordinary image files for normal website delivery. It is best used where a text representation is specifically required. Choosing another file or changing output format immediately removes the previous preview, output, error, busy state, and copy status. Every file read and browser decode belongs to a generation. A late completion from an older file cannot overwrite a newer selection. Temporary ObjectURLs are revoked on replacement, validation failure, format changes, and component unmount. If createImageBitmap exists and rejects the image, the converter reports that failure instead of hiding it behind a second decoder path; an HTMLImageElement fallback is used only when the API is unavailable. Copying is also asynchronous and generation guarded, so an old clipboard promise cannot publish a misleading Copied status after the result changes. Clipboard denial leaves the visible output available for manual selection and copying. Errors distinguish missing or empty input, excessive bytes, incomplete or unsupported containers, browser decode failure, invalid dimensions, excessive decoded dimensions, and excessive output length. No failure path leaves an earlier successful result visible. Supported means these four byte containers only; SVG, AVIF, HEIC, BMP, TIFF, PDF, and arbitrary text are outside scope even if a browser or file extension calls them images. Use a dedicated converter first if you need a different format. For the reverse workflow, use Base64 to Image. For general text rather than an image container, use Base64 Encode and Decode. For smaller output, optimize the original file with Image Compressor before encoding. For new dimensions, use Image Resizer before encoding. Keeping these tasks separate avoids hidden recompression and makes the output predictable. Treat an unknown image as untrusted content even though it stays local: successful browser decoding verifies technical readability, not authorship, truthfulness, accessibility, copyright status, moderation safety, or freedom from concealed data.

Methodology & sources

The widget checks the browser-reported file size before reading and verifies the resulting ArrayBuffer length again. A shared pure detector requires complete structural boundaries for PNG, JPEG, GIF, or WebP and supplies the trusted MIME; filename and declared MIME never select output. A Blob built with that detected MIME must decode through createImageBitmap, with HTMLImageElement used only when the API is unavailable; decoder rejection is normalized to an explicit no-result error. Positive integer dimensions are limited to 20,000 pixels per edge and 40,000,000 total pixels. A manual RFC 4648 encoder processes three-byte-aligned chunks without variadic whole-buffer conversion, emits canonical padding, and never truncates. The 5,242,880-byte input boundary, calculated Base64 length, and 6,990,531-character maximum output boundary are checked exactly. Unknown output modes fail rather than silently becoming plain Base64. Generation counters, mounted guards, copy generations, timer-identity cleanup, and ObjectURL revocation prevent stale reads, stale clipboard status, and resource leaks.

Frequently asked questions

Does Image to Base64 upload or store my file?
No. File reading, container detection, browser decoding, Base64 encoding, preview creation, and copying happen in the current browser tab. Temporary ObjectURLs are revoked when the result changes or the tool closes.
What happens if the filename or MIME type is wrong?
They are ignored for format selection. The converter recognizes a complete PNG, JPEG, GIF, or WebP container from its bytes, validates it with the browser, and uses that detected MIME in data URL mode.
Does conversion resize, recompress, or remove image metadata?
No. The Base64 payload represents the original validated file bytes exactly. The tool does not use canvas or rewrite the image, and the preview size is only a display constraint.
Why is Base64 output larger than the image file?
Base64 represents each three input bytes with four text characters, so it usually adds about one third before any data URL prefix. Use ordinary image files and URLs unless a text representation is required.

Related tools

Image Tools guides

View all