ColorArchive
Log 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

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.

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.

How the 2016 colors are generated

Every color in the archive is produced algorithmically in src/data/colors.ts at build time — no database, no external color API. 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.

2016
Total colors

36 × 7 × 8 = 2016 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.
Open updatesSupportFree sample