Build the source system
Start from randomized Brand, a preset, an import or a saved local theme. Add only the roles you need, then choose the readability policy that generates foregrounds.
BuildGuide / Start here
From one color to framework-ready design tokens.
Generate complete scales, inspect real interfaces, verify foregrounds and contrast, then export without coupling your system to one framework.
Source → system
Source colors01
50–950 scales02
Semantic roles03
Five adapters04
--color-primary → semantic.primary → adapterFour-step workflow
Build. Preview. Check. Export.
Each stage owns one job. Source editing and generated output stay separate throughout.
Preview real contexts
Use Interface for operational patterns or Composed examples for cards, websites, dashboards, components, charts, gradients and Palette Lab.
PreviewCheck both modes
Review the active policy, WCAG AA or WCAG AAA independently—or compare all three—across light and dark modes.
CheckExport the system
Save a local checkpoint, choose one of five adapters, inspect and download generated code, copy a route-native link or back up the complete workspace.
ExportWorkspace anatomy
Four destinations, four clear outcomes.
01
Build
Choose a starting source, edit families, load local themes and define foreground policy.
Source system
02
Preview
Switch between Interface and Composed examples without changing theme data.
Visual evidence
03
Check
Inspect active-policy, WCAG AA and WCAG AAA evidence separately or together.
Quality evidence
04
Export
Choose adapter, inspect output, download code, share or back up settings.
Developer handoff
Know the difference
Random, reset and shuffle do different jobs.
Randomize palette
Changes every active source value.
Keeps roles, gaps, custom count, status presence and current route.
Reset
Returns to one new randomized Brand color.
Removes added colors and returns to Build; named local themes stay.
Shuffle mix
Remixes Palette Lab widget roles and shades.
Preview-only: source colors, saved themes and exports never change.
How it works / Contrast
One policy for generation. Independent lenses for checking.
Build defines how foregrounds are selected for each role. Check measures the generated pairs against the active policy, WCAG AA or WCAG AAA without silently changing your source colors.
01 / Choose
Role-based foreground strategies
Balanced is the default profile. Actions, statuses and shade labels use Y/luma with a WCAG guard; body and large text choose the stronger light-or-dark WCAG candidate. Strict AA and Enhanced use maximum contrast, while Custom exposes every role.
Y′ = (299R + 587G + 114B) / 1000The Y/luma candidate selects #111318 at Y′ ≥ 128 and #FFFFFF below it. The guarded strategy keeps that candidate only when it reaches the role threshold; otherwise it flips to the stronger candidate. The weights follow ITU-R BT.601. Selection alone never proves conformance.
02 / Validate
WCAG contrast ratio
Tintary calculates relative luminance from linearized sRGB, then compares the lighter and darker colors through Culori.
contrast = (L1 + 0.05) / (L2 + 0.05)Active policy uses the thresholds configured in Build. WCAG AA checks 4.5:1 for normal text and 3:1 for large text and non-text cues. WCAG AAA raises normal text to 7:1 and large text to 4.5:1. Compare shows the three reports together; both light and dark modes are always checked.
1. Select
Each semantic role chooses Y/luma, maximum WCAG or the guarded hybrid.
2. Measure
Culori calculates the WCAG ratio for the actual foreground/background pair.
3. Report
Check reports Active policy, AA and AAA independently without mutating colors or exports.
APCA is intentionally outside Contrast Policy v1. Its result depends on typography context that a color-only MVP does not model, and the WCAG 3 specification is still evolving.
Portable by design
The URL carries the palette.
Canonical paths store active source colors and preview location. Custom colors use compact c1, c2 aliases.
Shareable route
/colors/ffcc00/cc0099/e4268f
/preview/cardsPath: source colors + active preview.
Hash: versioned non-color workspace settings.
Handoff
One model. Five adapters.
Generated colors come from the same ThemeDefinition. Export format changes; color logic does not.
01
CSS variables
02
Tailwind v4
03
Material UI
04
Bootstrap 5.3
05
Figma tokens
Local autosave
Current workspace remains in browser localStorage.
Named themes
Save up to 20 local semantic snapshots.
JSON backup
Download and validate a portable versioned workspace file.
FAQ
Common questions.
Does Tintary upload my palette?+
No. Workspace persistence uses browser localStorage. Sharing is stateless: colors live in the URL path and non-color workspace settings live in a versioned hash.
What is the difference between source colors and semantic tokens?+
Source colors are inputs. Tintary turns them into raw shade scales, then maps those scales to stable roles such as background, surface, primary, accent, success and border.
Will Reset delete my saved local themes?+
No. Reset rebuilds the current workspace from one random Brand color, but named local theme snapshots remain available.
Which contrast method does Tintary use?+
You choose by role. Y/luma preserves the intended visual direction, Maximum WCAG chooses the stronger light-or-dark candidate, and Y/luma + WCAG guard keeps Y/luma only when it reaches the rule threshold. Check measures the resulting pair separately.
Next step
Begin in Build. Leave through Export.
Start with one randomized color, add only needed roles, then move through visible evidence before handoff.