Evaluating Design Handoff Tools by the Specifications, Tokens, and Licensing They Produce

Zeplin's free tier limits you to 1 project and 12 screens. That constraint exposes the real test of a handoff tool: not the interface it shows during a demo, but the specification, design tokens, and licensing compliance it delivers to the engineer. Evaluate every handoff tool by output quality and licensing, not by feature checklists.

A handoff tool ships code snippets, design token JSON, and vector assets. Each has a failure mode that a visual demo never shows.

CSS Output Accuracy

Figma Dev Mode, on the Professional plan (Figma sets the price; check their site for the current rate), generates CSS from the layer panel. It reads measurement units from the file. Set a padding to 16 px in the design and the CSS outputs 16 px. That is accurate only if the engineer's CSS reset uses the same root font size. The browser default is 16 px, so a 16 px padding equals 1 rem. If the design uses points instead of pixels, a common error in print-to-screen workflows, the CSS outputs 1.333 px per point. A 16 px padding becomes 21.3 px. The tool passes the visual check but fails the unit conversion.

Design Token Export And The W3C Standard

The W3C Design Tokens Community Group defines a JSON format for token values: colour, spacing, typography, motion. No major handoff tool exports W3C-conformant token JSON by default. Zeplin exports tokens as a flat key-value list. Figma Dev Mode exports component properties (variant, text, boolean, instance swap) but not as a token tree. The engineer must manually map the exported values to the token structure. That reintroduces the translation error the tool was supposed to eliminate. A tool that claims token support but does not produce W3C-format JSON is claiming feature parity without delivering the spec.

SVG Asset Export Integrity

Vector asset export should produce a single SVG file per icon or logo. Figma and Zeplin both export SVG. The file may include Figma-specific metadata tags, ungrouped shapes, or a viewBox that does not match the icon's bounding box. An engineer who opens the SVG in code and finds an extra 4 px of transparent space around the icon has to trim it manually. The export function did not fail. The SVG renders identically on screen. But the output is not production-ready without manual cleanup.

The SIL Open Font License version 1.1 (2007) permits use, study, modification, and redistribution. It explicitly forbids selling the font alone and requires any derivative to use a different reserved name. It does not forbid embedding in a SaaS tool that generates PDFs. The OpenType fsType bit, stored in the OS/2 table, does: it encodes the font's embedding permissions. A font with fsType set to 2 (restricted embedding) cannot be embedded in a PDF at all. A font with fsType set to 4 (preview & print) can be embedded only for viewing and printing, not for editing or extraction.

A handoff tool that extracts font files from the design file and sends them to the engineer is violating the fsType bit if the font is restricted. A tool that references fonts, listing the font family and weight without providing the file, stays within the license. The difference is legally and operationally critical. The engineer who receives a font file from the handoff tool may be using it outside the license terms, and the designer who selected the font is liable.

Google Fonts supplies typefaces under open licenses, so its fonts are safe to embed. A subscription service like Adobe Fonts or a commercial foundry such as Monotype or Linotype imposes per-title embedding agreements. The desktop license covers installation on a fixed number of workstations. The webfont license binds to pageviews per month or a domain. The app font license requires a per-title embedding or enterprise agreement. A handoff tool that extracts a font from a design file without checking which license applies is generating an illegal asset. Verify the font's embedding permission before the engineer ever opens the handoff spec.

Tool	Output Format	Common Failure	Licensing Risk
Figma Dev Mode (Professional; check Figma's pricing page for current rate)	CSS, SVG, component property JSON	px-to-rem conversion error; SVG metadata tags	No font extraction; references only
Zeplin (Free tier: 1 project, 12 screens; Team: check Zeplin's pricing page for current rate)	CSS, token key-value list, SVG, redlined PDF	Token export is flat, not W3C tree; SVG bounding box mismatch	No font extraction; references only
Penpot (.penpot file)	CSS, SVG, token JSON (partial)	Token JSON not W3C conformant; SVG may include ungrouped shapes	No font extraction; references only
Framer (.framer file)	React code, CSS, SVG	Code snippets optimised for Framer runtime, not production CSS	No font extraction; references only

Redlining, the practice of annotating a design with spacing, size, and typography values, is the core of a handoff spec. A redlined PDF from Zeplin or a Dev Mode annotation from Figma must specify measurement units explicitly. The failure occurs when the tool outputs a number without the unit. "padding: 16" in the inspection panel could be 16 px, 12 pt (16 px at 96 dpi), or 1 rem (16 px at browser default). The engineer who guesses wrong introduces a layout bug. The visual check does not catch it because the difference is invisible at full width.

WCAG 2.2 target size annotation is a specific case. The standard requires touch targets of at least 24 CSS pixels. iOS points measure at 1 pt = 1 px at @1x, but a 24 px target at @3x is 72 px, not 24 pt. A redline that says "touch target: 24" without specifying the unit causes the engineer to implement a 24 pt target on iOS. That is 32 px at @2x, below the WCAG minimum. The handoff tool that annotates in points without converting to CSS pixels produces an accessibility failure that passes visual review.

Before you export the handoff spec, verify four things:

• Measurement units: every spacing, size, and typography value includes the unit (px, pt, rem, dp). The engineer's CSS framework may use a different base, so annotate the expected conversion.
• Font embedding permission: check the font's fsType bit in the OpenType OS/2 table. If the bit is 2 or 4, the handoff tool must not extract the font file. Reference the font by name and weight only.
• Colour space metadata: if the design uses RGB, the SVG export must include the sRGB ICC profile (IEC 61966-2-1:1999). If the design uses CMYK, the export must include the correct ICC profile. Use FOGRA51 for European coated, SWOP 2013 for US web offset. The rendering intent must be relative colorimetric for vector graphics.
• Asset compression: SVG icons should not include compression artefacts. PNG exports from the handoff tool should use a minimum of 24-bit colour with alpha transparency, not 8-bit indexed colour that introduces banding on gradients.

Figma Dev Mode, released in 2023 and included with the Professional plan (check Figma's pricing page for the current rate), provides an inspection panel that displays spacing, size, text properties, and component properties. It is not a substitute for a redlined PDF or a token export. The limitations are concrete.

No Style Guide Generation

Dev Mode shows the properties of the selected layer. It does not generate a style guide document that lists all colours, type styles, and spacing values used across the file. The engineer must inspect each component individually. That guarantees missed values and manual transcription errors.

No Version History In The Inspection View

The inspection panel reflects the current state of the file. If the designer updates a colour token after the engineer has started implementation, the engineer sees the new value only by refreshing the inspection panel. There is no diff view that shows what changed between versions. An engineer who does not refresh introduces a discrepancy between the design and the code.

No Code Snippet Accuracy Guarantee

Figma's CSS output is syntactically correct but not always semantically accurate. It outputs fixed values where the design uses a component property. A button's padding is output as the specific value in the inspected instance, not as a reference to the padding token. The engineer who copies the CSS snippet into the codebase hardcodes a value that should be tokenised. The visual check passes. The code is not maintainable.

The W3C Design Tokens Community Group published a draft specification for a JSON format that defines token types (colour, dimension, font family, shadow) and their values in a machine-readable tree. A tool that exports tokens in this format allows the engineer to import the JSON directly into a design system library (Material Design 3, Apple Human Interface Guidelines, or a custom token set). A tool that exports tokens as a flat list or as component properties forces the engineer to restructure the data manually.

No major handoff tool exports W3C-conformant token JSON as of 2026. Zeplin's token export is a key-value list with no type annotation. Figma Dev Mode's component property export includes variant, text, boolean, and instance swap types, but the export is not structured as a token tree. Penpot's token JSON is closer but still does not conform to the W3C draft. The engineer who receives a token export from any of these tools must rewrite it to match the design system's token structure. That rewrite is where the specification breaks. A colour value of #1A1A1A in the tool's export may become --color-surface: #1A1A1A in the engineer's code, but the tool's export does not include the semantic name. The engineer has to infer it from the layer name. Errors creep in.

The solution is to use a dedicated token management tool, such as a Figma plugin that exports W3C-format JSON. Treat the handoff tool's token export as a starting point, not the final deliverable. The handoff tool's feature list says "token export." The real question is whether the export matches the W3C format.

Rework in the handoff phase costs time and trust. These five checks eliminate the most common causes.

Check 1: Confirm The Font Embedding Permission

Open the font file in a font editor or use a command-line tool like fonttools to read the fsType bit in the OS/2 table. If the bit is 2 (restricted) or 4 (preview & print), the handoff tool must not extract the font file. Reference the font by name and weight, and instruct the engineer to source it from the licensed location.

Check 2: Verify The Colour Space And ICC Profile

If the design uses RGB, the export must include the sRGB ICC profile. If the design uses CMYK, the export must include the correct profile for the target print condition, FOGRA51 for European coated, SWOP 2013 for US web offset. An engineer who opens a CMYK SVG without the ICC profile sees the colours in the default colour space of the browser or OS. The appearance shifts.

Check 3: Measure The Touch Targets In CSS Pixels

WCAG 2.2 requires touch targets of at least 24 CSS pixels. Convert points to pixels: 1 pt = 1.333 px at 96 dpi. A 24 pt target is 32 px, which passes. A 16 pt target is 21.3 px, which fails. Annotate every touch target with the CSS pixel value, not the design file's point value.

Check 4: Test The SVG Export For Clean Code

Export one icon from the handoff tool and open it in a text editor. Look for Figma metadata tags (, ), ungrouped shapes ( without a class), and a viewBox that does not match the icon's bounding box. The SVG should contain only the path data, a viewBox that exactly frames the icon, and no extra grouping.

Check 5: Annotate The Measure Range For Body Text

The typographic measure for continuous English text should be 45 to 75 characters per line, as documented by Robert Bringhurst in The Elements of Typographic Style. The handoff tool's redline may show the text frame width in pixels, but the engineer needs the character count. Annotate the measure as a character range, not a pixel width.

This evaluation method suits the early-career designer who needs to defend decisions with standards rather than taste, and who must learn that a tool's demo interface does not predict the accuracy of its CSS output or the legality of its font extraction. It suits the in-house designer at a non-design organisation who is the only design-literate person in the room and needs to cite the SIL Open Font License server clause or the W3C Design Tokens Community Group draft to justify tool selection. It suits the engineer who commissions or implements design and needs to speak the craft's specification language (measurement units, ICC profiles, fsType bits) without being sold on feature lists.

It does not suit anyone seeking design inspiration or portfolio critique. The focus is constraints and specifications, not visual examples. It does not suit anyone shopping for design software by subscription price. The Zeplin team plan and Figma Dev Mode Professional plan costs change annually. The tool's pricing page is the only current source. The one thing that most often goes wrong is the designer trusting the handoff tool's visual preview over the concrete output the engineer receives. A CSS snippet passes the visual check but fails on font embedding permissions, colour space metadata, or touch-target measurement units.