About

Base64 encoding inflates file size by approximately 33.3% due to the 3-byte to 4-character mapping ratio. Embedding an APNG animation that weighs 150KB on disk will consume roughly 200KB inside your HTML or CSS. Misusing inline encoding on assets above 50KB degrades page load time and bloats the DOM, which directly harms Core Web Vitals scores. This tool validates the PNG signature header (89 50 4E 47) and confirms the presence of the acTL animation control chunk before encoding, so you never accidentally treat a static PNG as animated or ship a corrupt string to production.

All conversion runs client-side in the browser. No file data leaves your machine. The tool produces four output formats: raw Base64, Data URI with correct image/apng MIME type, a CSS background-image declaration, and an HTML <img> element. Note: browsers that lack APNG support (older IE/Edge) will render only the first frame as a static PNG fallback. Pro tip: for assets under 10KB, inline Base64 eliminates an HTTP request and can improve performance; above that threshold, a separate file with proper caching is almost always faster.

Formulas

Base64 encoding maps every group of 3 input bytes to 4 ASCII characters drawn from a 64-character alphabet (A−Z, a−z, 0−9, +, /). The encoded output length is computed as:

L_base64 = 4 ⋅ ceil(n3)

where n = original file size in bytes and L_base64 = resulting character count. The size inflation ratio is therefore:

R = L_base64n ≈ 1.333

For a Data URI, the total payload adds a prefix string of fixed length:

L_total = len(prefix) + L_base64

where prefix = data:image/apng;base64, (24 characters). APNG detection relies on scanning PNG chunks. Each chunk has the structure: 4-byte length, 4-byte type, variable data, 4-byte CRC. The presence of a chunk with type bytes 61 63 54 4C (ASCII: acTL) confirms animation capability.

Reference Data

Property	APNG	GIF	WebP	AVIF
Max Colors	16.7M (24-bit + alpha)	256	16.7M	16.7M
Alpha Channel	8-bit transparency	1-bit (on/off)	8-bit transparency	8-bit+ transparency
Compression	Lossless (deflate)	Lossless (LZW)	Lossy + Lossless	Lossy + Lossless
Animation Support	Yes (via acTL/fcTL/fdAT)	Yes (native)	Yes	Yes (AVIF sequence)
Browser Support (2024)	96%+	100%	97%+	92%+
Typical File Size (100×100 animation)	50−200KB	80−300KB	30−120KB	20−80KB
MIME Type	image/apng	image/gif	image/webp	image/avif
Base64 Size Overhead	~33.3%	~33.3%	~33.3%	~33.3%
PNG Signature (hex)	89 50 4E 47 0D 0A 1A 0A
Animation Chunk	acTL (animation control)	Application Extension Block	VP8 bitstream	AVIF ItemProperties
Frame Chunk	fcTL (frame control) + fdAT (frame data)	Image Descriptor per frame	ANMF chunk	Sequence items
Fallback (no animation support)	Displays default IDAT as static PNG	Shows first frame	Shows first frame	Shows poster frame
Max Dimensions	2³¹−1 px per axis	65,535 px	16,383 px	65,536 px
Recommended Max for Base64 Inline	10KB original → ~13.3KB encoded
Data URI Prefix	data:image/apng;base64,	data:image/gif;base64,	data:image/webp;base64,	data:image/avif;base64,
Spec / Standard	APNG Spec (Mozilla) + PNG ISO/IEC 15948	GIF89a (CompuServe)	Google/WebM Project	AOM / ISO/IEC 23000-22

Frequently Asked Questions

Both APNG and static PNG share the same 8-byte file signature (89 50 4E 47 0D 0A 1A 0A). The converter parses the binary chunk structure and looks for the acTL (Animation Control) chunk type. This chunk stores the total frame count and loop count. If acTL is absent, the file is a standard static PNG. If present, the file is confirmed as APNG and encoded with the image/apng MIME type in the Data URI output.

Yes, as long as the viewing browser supports APNG rendering (96%+ of modern browsers including Chrome 59+, Firefox 3+, Safari 8+, Edge 79+). The Data URI preserves the full binary payload including all fcTL frame control and fdAT frame data chunks. Browsers that lack APNG support will render the default IDAT image data as a static fallback frame, which is the standard PNG behavior defined in the spec.

There is no hard technical limit, but performance degrades sharply above 50 KB original size (~67 KB encoded). Inlining a 500 KB APNG produces roughly 667 KB of text in your HTML, which the browser must parse as a string before decoding. For assets above 10-20 KB, using a standard file reference with HTTP/2 multiplexing and cache headers will almost always outperform inline embedding. This tool accepts files up to 10 MB but displays a warning above the 50 KB threshold.

No. Base64 is a lossless binary-to-text encoding scheme. Every byte of the original APNG file is preserved exactly. Frame delays (stored in fcTL chunks as delay_num/delay_den fractions), dispose operations, blend operations, and color data remain bit-identical after decoding. The only change is representation format: binary bytes become ASCII characters at a 4:3 ratio.

The background shorthand property resets all sub-properties (background-size, background-position, background-repeat) to their initial values when declared. Using background-image specifically sets only the image source, preserving any other background properties you may have defined elsewhere in your stylesheet. This prevents accidental layout breaks when pasting the generated CSS into existing code.

Technically yes, but email client support is inconsistent. Gmail strips Data URIs from img src attributes for security reasons. Outlook renders only static PNGs regardless. Apple Mail and Thunderbird support inline Base64 images including APNG animation. For email, hosting the APNG on a CDN and referencing it via an absolute URL is the reliable approach. The raw Base64 output from this tool can still be useful for embedding in email builder tools that handle encoding internally.