Skip to content
Library design

User-Agent Parsing Is Heuristic. I Designed the API to Admit It

A tiny, type-safe client classifier with User-Agent, Client Hints, and HTTP header support.

Written by Montasim
2 min read

client-parser interface preview

The visible feature was only the surface

Analytics and diagnostics need a normalized view of client strings and hints, while many parsers are heavy or encourage unsafe use of inherently heuristic data.

The system also had to respect concrete constraints. User-Agent classification is heuristic and spoofable. Client Hints availability varies and may be privacy-restricted. Results cannot safely drive authentication, authorization, or capability decisions.

My role covered library design and package engineering, with responsibility for typed apis, compatibility, and package distribution.

I turned the constraints into boundaries

Pure parsing/normalization rules and typed result model; zero-dependency dual-module package; workspace-linked playground/docs and regression corpus.

State the heuristic boundary explicitly and recommend feature detection for behavior.

Combine User-Agent and Client Hints through one normalized output.

Remain zero dependency and pre-1.0, accepting a maintained rule/test corpus and changelog review.

The key decision: State the heuristic boundary explicitly and recommend feature detection for behavior.

The implementation had to prove the model

I delivered the work across the full path: Implemented browser, OS, device, mobile, and bot classification. Added Client Hints support and normalized typed results. Created representative regression tests and package builds. Built a local-input playground without requiring a server parser.

The result is concrete: Consumers can classify common client strings. Enrich results with available hints. Distinguish bots/devices/browsers for analytics or presentation. Inspect parsing behavior interactively.

The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.

Working through a similar challenge?

Share your context, constraints, and timeline to start a focused conversation.

Discussion

Join the conversation about this article

0 comments

Loading discussion

Fetching the latest comments.

Leave a reply

Respond to the article or continue the discussion.

Ctrl + Enter to post

Your email stays private. Comments are stored securely.