Color Fonts and Emoji: Formats and Rendering

Send a smiling face emoji from an iPhone to an Android phone and it looks different. Send it to a Windows PC and it looks different again. This isn't a bug — it's four companies (Apple, Google, Microsoft, Mozilla) each designing their own emoji art and shipping it in their own font format on their own platform. The Unicode standard defines which emoji exist (code points and descriptions), but the visual design is entirely up to the platform vendor.

The fragmentation runs deeper than art style. The underlying font technology for rendering color glyphs also differs. Apple stores emoji as bitmap images inside fonts. Google uses both bitmaps and vectors. Microsoft uses layered colored vectors. Each approach has different rendering characteristics, file sizes, and browser support. This guide explains the four color font formats, why they exist, and where the technology is heading.

COLR/CPAL: Layered Vector Colors

COLR (Color) and CPAL (Color Palette) are companion OpenType tables that add color to vector glyph outlines. The approach is layered: each colored glyph is composed of multiple monochrome glyph layers, each painted with a color from the CPAL palette.

COLRv0: Flat Colors

The original COLR specification (COLRv0, 2013) supports flat solid colors only. Each emoji is built from stacked vector shapes, each filled with one solid color. Think of it as layered paper cutouts — a yellow circle, two black dots for eyes, a curved black line for a mouth. The result is a vector emoji that scales cleanly to any size but lacks gradients, blur, or photorealistic effects.

COLRv0 is supported by Chrome, Firefox, Edge, and recent Safari. It's compact (vector data is small) and resolution-independent. Microsoft uses COLRv0 for the Segoe UI Emoji font on Windows.

COLRv1: Gradients and Effects

COLRv1 (2021) extends COLR with gradients (linear, radial, sweep), compositing modes, and affine transformations. This enables much richer color glyph rendering — closer to SVG capabilities but in a more compact binary format.

Google adopted COLRv1 for Noto Color Emoji. Chrome 98+ (early 2022), Firefox 107+ (late 2022), and Edge support COLRv1. Safari added support in 2024. COLRv1 is emerging as the convergence point for color fonts because it's vector-based (scalable), compact (smaller than bitmap alternatives), and gaining broad support.

File size comparison for Noto Color Emoji:
CBDT (bitmap): ~10 MB
COLRv1 (vector): ~1.5 MB

That 85% size reduction, combined with resolution independence (no pixelation at any zoom level), makes COLRv1 the clear technical winner.

SBIX: Apple's Bitmap Approach

SBIX (Standard Bitmap Graphics) stores emoji as embedded PNG or JPEG images at multiple resolutions. Apple Color Emoji uses SBIX with bitmap images at 20px, 32px, 40px, 48px, 64px, 96px, and 160px sizes. The browser (or OS renderer) picks the closest resolution to the rendered size and scales if needed.

Tradeoffs

• Photorealistic quality: Bitmap emoji can include complex textures, lighting, and gradients that vector formats struggle to reproduce. Apple's emoji designs use this extensively — the glossy, 3D look is achieved with pre-rendered bitmap art
• Large file size: Apple Color Emoji is approximately 170 MB (yes, megabytes) because it stores bitmaps at seven resolutions for ~3,600 emoji. This is never a web font concern — it's bundled with macOS/iOS, not downloaded
• Pixelation at extreme sizes: Bitmap emoji pixelate when displayed larger than the largest stored resolution. At 160px and below, Apple's emoji look crisp. Above 200px, they start showing interpolation artifacts
• Platform exclusive: SBIX is effectively Apple-only. Other browsers on macOS render Apple Color Emoji via the operating system, not via browser-level SBIX support

CBDT/CBLC: Google's Bitmap Format

CBDT (Color Bitmap Data Table) and CBLC (Color Bitmap Location Table) store emoji as embedded PNG bitmaps, similar to SBIX but using a different table structure. Google uses CBDT/CBLC for Noto Color Emoji on Android.

The format has the same tradeoffs as SBIX: photorealistic quality at stored resolutions, large file size (~10 MB for Noto Color Emoji), and pixelation at extreme sizes. Google is transitioning Noto Color Emoji from CBDT to COLRv1, reducing size from 10 MB to 1.5 MB while gaining resolution independence.

CBDT/CBLC is supported by Chrome, Firefox, and Edge. Safari does not support it natively but doesn't need to — Apple devices use SBIX via Apple Color Emoji.

SVG-in-OpenType: The Flexible Option

The SVG table in OpenType stores glyph graphics as SVG documents — full SVG with paths, gradients, filters, and even animation. This is the most capable format: anything SVG can render, an SVG-in-OpenType color font can render.

Support and Usage

Firefox was the primary champion of SVG-in-OpenType. Mozilla used it for the Twemoji Mozilla font (based on Twitter's emoji designs). Safari added SVG-in-OpenType support for its emoji rendering.

Chrome dropped SVG-in-OpenType support in Chrome 119 (late 2023) in favor of COLRv1. This was a controversial decision — SVG-in-OpenType is more capable, but COLRv1 is faster to render and produces smaller files. The Chrome team argued that COLRv1 covers 95%+ of use cases and renders significantly faster because it doesn't require a full SVG rendering pipeline.

The practical impact: SVG-in-OpenType color fonts work in Firefox and Safari but not in Chrome or Edge. For web-facing color fonts, COLRv1 is the safer choice. For specialized uses (animated emoji, complex color typography), SVG-in-OpenType remains the only option in non-Chromium browsers.

System Emoji Fonts by Platform

Every major platform ships its own color emoji font. Users never download these — they're installed as part of the operating system.

Emoji Fonts Across Platforms

The size difference between Apple's bitmap approach (170 MB) and Google's COLRv1 approach (1.5 MB) illustrates the format debate. Bitmaps look richer but cost 100x the storage. As display resolutions increase (requiring even larger bitmaps), vector formats become increasingly practical.

Why Emoji Look Different Everywhere

The Unicode Consortium defines emoji by code point and text description. U+1F600 is "grinning face." What a "grinning face" looks like is up to the platform vendor. Apple designs 3D-styled faces with highlights and shadows. Google designs flat, rounded faces. Microsoft designs flat Fluent-style faces. Samsung historically designed their own divergent interpretations (though they've converged closer to Apple's designs in recent years).

This causes real communication problems. The "grimacing face" (U+1F62C) looked like a pained grimace on Apple but a happy grin on Samsung — sending it meant different things depending on the recipient's platform. Platform vendors have gradually converged their designs to reduce these mismatches, but meaningful differences persist.

There is no way to force cross-platform emoji consistency via CSS. The font-family declaration can specify an emoji font, but system emoji fonts aren't available cross-platform. The closest solution is Twemoji (Twitter's open-source emoji set), rendered as SVG or PNG via JavaScript. This gives consistent rendering but requires loading the emoji art as external assets rather than using system fonts.

Custom Color Fonts for the Web

Color fonts aren't limited to emoji. Type designers are creating color fonts with gradient fills, multi-colored letters, chromatic layering, and decorative effects. These use COLRv1 for maximum compatibility:

@font-face {
  font-family: 'Bungee Color';
  src: url('/fonts/BungeeColor-Regular.woff2') format('woff2');
  font-display: swap;
}

h1 {
  font-family: 'Bungee Color', 'Bungee', sans-serif;
  /* Falls back to monochrome Bungee if color isn't supported */
}

Notable color fonts: Bungee Color (layered block letters), Gilbert Color (multi-color gradient), and Rocher Color (3D rock texture). These are primarily decorative — used for headings, logos, and hero text. Body text should always use monochrome fonts.

Browser support for COLRv1 color fonts is at 90%+ (Chrome 98+, Firefox 107+, Safari 18+, Edge). For browsers that don't support the color tables, the font falls back to its monochrome glyph outlines — text still renders, just without color.

Twemoji: Cross-Platform Emoji Consistency

Twemoji (originally Twitter's, now maintained by the open-source community) provides a consistent set of emoji as SVG files. Instead of relying on system emoji fonts (which vary by platform), Twemoji replaces emoji characters with SVG images:

<!-- Via CDN (simple but adds third-party dependency) -->
<script src="https://cdn.jsdelivr.net/npm/@twemoji/api/dist/twemoji.min.js"></script>
<script>twemoji.parse(document.body);</script>

<!-- The script finds emoji characters and replaces them with <img> tags -->
<!-- Before: 😀 -->
<!-- After: <img class="emoji" alt="😀" src="https://cdn.jsdelivr.net/..."> -->

Twemoji guarantees identical emoji rendering on all platforms. The trade-off: each emoji loads an SVG image (1-3 KB each), adding HTTP requests and HTML weight. For chat applications or sites with heavy emoji usage, the consistency is worth it. For occasional emoji in blog posts, system emoji fonts are fine.

The color font landscape is converging on COLRv1. It's vector-based (scales to any size), compact (10x smaller than bitmap alternatives), and has browser support above 90%. Apple still uses SBIX for its premium bitmap emoji art, but even Google — the other bitmap holdout — is migrating Noto Color Emoji to COLRv1.

For web developers, the practical advice is simple: system emoji render automatically, no action needed. If you need cross-platform consistency, use Twemoji. If you want decorative color text for headings, COLRv1 color fonts work in all modern browsers with a monochrome fallback. For working with font files across formats, you can convert TTF to WOFF2 or convert OTF to WOFF2 — both conversions preserve color font tables.