Principle
Static by design
The catalog still ships as static pages, but lightweight API endpoints now handle commerce, email, analytics, and optional account sync via magic link or Google sign-in.
About ColorArchive
A static color library with product intent
ColorArchive started as a color archive and expanded into a lightweight static product: discovery routes, reusable palette exports, and product layers that can later support off-site checkout.
Principle
Curated, not exhaustive
ColorArchive does not try to dump the entire RGB universe into one page. It focuses on a large but navigable archive with structure.
Principle
Useful, not ornamental
Every route should either help someone find, compare, export, reuse, or eventually buy a color system.
By the numbers
5,446
Colors
14
Collections
7
Packs
23
Guides
31
Notes
9
Families
How the 5,446 colors are generated
Every color in the archive is 100% procedurally generated via our proprietary algorithm in src/data/colors.ts at build time — no database, no external color API, no scraped or copyrighted data. The generation multiplies three HSL dimensions: hue roots, lightness bands, and chroma bands.
36
Hue roots
Evenly spaced hues across 0–360° in 10° increments.
7
Lightness bands
From near-white (95%) down to near-black (15%), stepped for perceptual evenness.
8
Chroma bands
Saturation steps from muted (12%) to vivid (95%), giving each hue depth.
5,446
Total colors
48 hues × 14 lightness × 8 chroma + 5 neutral groups × 14 = 5,446 unique HSL entries. All generated in colors.ts at build time.
Each color gets a stable slug derived from its HSL values, so every color detail page can be pre-rendered with
generateStaticParams() and served as flat HTML — no runtime needed.Hosting tradeoffs
GitHub Pages (current)
Pros
- Free, zero-ops
- Forces static discipline
- Great for the archive surface
Tradeoffs
- Needs a separate API host
- Checkout must be off-site
- Dynamic features live elsewhere
Vercel / Netlify
Pros
- Edge functions available
- Instant deploy previews
- Could consolidate frontend and API
Tradeoffs
- Paid tier for team use
- Adds infra dependency
Full backend (if needed)
Pros
- Licensed downloads
- Deeper account features
- API for token generation
Tradeoffs
- Auth complexity
- Database ops
- Higher cost and maintenance
The current GitHub Pages setup is still the right default for the archive UI. Dynamic features already run on a separate API host, which keeps the browsing layer static while still supporting checkout webhooks, email delivery, analytics, and account sync.