Origin
Base64 comes from the old need to move binary data through text-only systems. Email, protocols, and configuration files often expected printable characters, not arbitrary bytes. Base64 maps binary data into a restricted alphabet that survives those channels.
When used with images, Base64 is usually seen inside a data URL: a string that begins with a media type such as data:image/png;base64, followed by encoded image bytes.
Technical characteristics
Base64 is not compression. It usually makes data larger because every three bytes become four text characters, before any outer gzip or Brotli compression is applied. It also hides the normal browser caching boundary: an embedded image travels with the HTML or CSS instead of being cached as a separate file.
Its advantage is portability. A tiny icon, placeholder, test image, or email-safe asset can live inside one document with no separate file request. That can be convenient in demos and fixtures, but painful for real pages when overused.
Where it fits
Use Base64 for very small images, embedded examples, CSS placeholders, JSON fixtures, and cases where a single self-contained file matters more than cache efficiency. Do not use it to inline large photos or galleries.
A practical rule: if the encoded string is longer than you would want to read in a code review, make the image a real file.
Best uses
- Tiny inline icons or placeholders
- Self-contained demos and tests
- Moving image bytes through text-only channels
Use another format when
- Large photographs
- Reusable production assets that should cache separately
- Human-maintained source files with long unreadable strings