About

Base64 encoding translates binary image data into an ASCII string using a 64-character alphabet (A - Z, a - z, 0 - 9, +, /). A raw JPEG file of 100 KB produces a Base64 string approximately 133 KB long due to the inherent 33% size overhead of the encoding scheme. This tool validates JPEG magic bytes (FF D8 FF) before encoding, preventing malformed output from spoofed file extensions. Processing occurs entirely in your browser via the native FileReader API. No data leaves your machine.

Incorrect Base64 strings break inline images in HTML emails, CSS background-image declarations, and JSON payloads. A single missing padding character (=) or a line-break inserted by a naive encoder renders the entire string invalid. This encoder produces specification-compliant output with optional Data URI prefix for direct embedding. Note: Base64 is not encryption. It provides zero confidentiality. Treat encoded strings containing sensitive imagery with the same caution as the original file.

Formulas

The size of a Base64-encoded string is determined by the ratio of 3 input bytes mapping to 4 output characters, with padding to ensure the output length is a multiple of 4.

L_base64 = 4 ⋅ ceil(n3)

where L_base64 = length of the encoded string in characters, and n = number of input bytes. The decoded byte size from a Base64 string can be recovered as:

n = 34 ⋅ L_base64 − p

where p = number of padding = characters (0, 1, or 2). Each group of 6 bits indexes into the Base64 alphabet. The encoding process splits 3 bytes (24 bits) into 4 groups of 6 bits. When re-encoding through Canvas at quality q (0.0 - 1.0), the JPEG encoder applies DCT quantization scaled inversely to q, reducing file size at the cost of visual fidelity.

Reference Data

Property	Value / Detail
JPEG Magic Bytes	FF D8 FF (first 3 bytes)
Base64 Alphabet	A - Z, a - z, 0 - 9, +, /
Padding Character	= (appended to make length divisible by 4)
Size Overhead	~33.3% larger than binary
Data URI Prefix (JPEG)	data:image/jpeg;base64,
Max Data URI (IE11)	4,096 bytes (obsolete browser)
Max Data URI (Modern)	No hard limit; practical < 2 MB
JPEG Quality Range	0.0 (worst) - 1.0 (best)
Encoding Standard	RFC 4648 §4
MIME Type	image/jpeg
Typical HTML Usage	<img src="data:image/jpeg;base64,...">
Typical CSS Usage	background-image: url(data:image/jpeg;base64,...)
Encoding Time (1 MB file)	< 50 ms (modern browser)
Common Use Cases	Email templates, JSON APIs, CSS sprites, offline apps
Binary-to-Text Ratio	3 bytes → 4 ASCII characters
Line Length (RFC 2045)	76 characters max per line (MIME)
URL-Safe Variant	Replaces + with -, / with _
File Extension	.jpg, .jpeg, .jfif
Color Space	YCbCr (converted from RGB)
Max Dimensions (JPEG)	65,535 × 65,535 px

Frequently Asked Questions

Base64 encodes every 3 bytes of binary data into 4 ASCII characters. This 4/3 ratio produces a fixed overhead of approximately 33.3%. A 750 KB JPEG will produce a Base64 string of roughly 1,000 KB (1 MB). This is inherent to the encoding and cannot be reduced without first compressing the source image.

A raw Base64 string contains only the encoded character data (e.g., /9j/4AAQSkZJRg...). A Data URI prepends the MIME prefix data:image/jpeg;base64, making it directly usable in HTML <img> tags, CSS url() functions, and most rendering contexts. Without the prefix, the browser cannot determine the data type and will fail to render the image.

Yes. The quality slider re-encodes the image via the Canvas API using canvas.toDataURL('image/jpeg', q) where q ranges from 0.0 to 1.0. At q = 1.0, quality loss is minimal but the file may actually grow larger than the original due to re-quantization. At q = 0.5, expect visible artifacts in gradients and text. For lossless pass-through, use the "Original (no re-encode)" option which reads the raw file bytes directly.

This tool checks the file's magic bytes. Valid JPEG files start with the hex sequence FF D8 FF. If a file has a .jpg extension but different magic bytes (e.g., a renamed PNG), the tool will reject it. This prevents generating a Base64 string with an incorrect image/jpeg MIME type that would fail to render in browsers.

The practical limit depends on your browser's available memory. Most modern browsers handle files up to 50 - 100 MB without issues. However, embedding Base64 strings larger than 2 MB in HTML documents degrades page load performance significantly. For large images, hosting the file externally and referencing via URL is the standard practice.

Yes, but use the raw Base64 string (without the Data URI prefix) and specify the MIME type in a separate JSON field. Example: {"type": "image/jpeg", "data": "...base64..."}. The Data URI prefix contains a colon and semicolons which, while valid in JSON strings, unnecessarily increase payload size and duplicate information that should be in metadata.