OpenBrand: The Open-Source Engine That Reconstructs a Website’s Brand Identity
From logos and colors to typography and imagery, OpenBrand turns hostile, messy pages into structured brand assets for developers, designers, and AI agents.
- OpenBrand is not a simple logo fetcher, it is a fallback-driven inference engine that rebuilds brand identity from weak signals.
- Its core advantage is resilience: when direct scraping fails, it still ranks partial evidence into usable brand assets.
- The project matters because brand context is becoming infrastructure for AI agents, design systems, and white-label products.
- Open source changes the economics of brand extraction by making the whole layer portable, self-hostable, and inspectable.
A brand engine, not a logo scraper
OpenBrand is interesting because it refuses the simplest answer. A favicon, a logo, or a theme color is never treated as the whole truth. Instead, the engine collects clues, scores them, and builds a brand dossier from whatever survives the web’s usual defenses.
That matters because modern sites are messy. They hide assets behind hashed paths, serve thin markup to crawlers, and return 403s when a scraper looks too obvious. OpenBrand is built for that reality, not for the clean demo case.
Why the web keeps refusing to cooperate
The hostile web shows up in a few predictable ways. Some pages block bots outright. Others expose only partial metadata, or bury the real logo in an SVG, a manifest, or a header element that a naive scraper never checks. OpenBrand assumes the first request may fail and designs around that assumption.
Why we built this: while building another product, we needed to pull in customers' brand images as custom backgrounds. It felt like a simple enough problem with no open source solution - so we built one.
How OpenBrand decides what is actually a logo
The clever part lives in the heuristic layer. In src/scraper.ts, OpenBrand does not just ask whether an image exists. It asks whether the image behaves like a logo. That means checking class-name hints, looking for header or footer placement, testing domain matches, and probing dimensions before deciding what gets promoted.
// The exact details vary by site, but the heuristic idea is simple:
// gather candidates, score them, then keep the best one.
const score = (candidate: Candidate) => {
let total = 0
if (candidate.inHeader) total += 3
if (candidate.className?.includes('logo')) total += 4
if (candidate.domainMatches) total += 2
if (candidate.aspectRatio > 1.4) total += 1
if (candidate.width >= 200) total += 1
return total
}
const best = candidates.sort((a, b) => score(b) - score(a))[0]That logic is the project’s real thesis. A brand is not a single asset. It is an inference problem, where weak signals become useful only when they agree with each other.
From URL to brand dossier
The public surface is straightforward. A normalized URL enters the API route, the extraction engine runs, results are cached, and the user gets a structured brand profile back. Underneath that, the system is doing more work than a one-off scraper ever could.
| Approach | What it gets right | Where it stops |
|---|---|---|
| OpenBrand | Open source, self-hostable, heuristic asset reconstruction | Depends on messy web data and rules that must keep evolving |
| Brand.dev | Managed convenience and likely deeper black-box coverage | Closed source, platform-controlled, less portable |
| Favicon-only lookup | Fast and trivial | Misses the logo, colors, imagery, and most of the brand surface |
That table is the real gap. A favicon-only approach is too shallow. A closed service may be convenient, but it keeps the brand layer inside someone else’s platform. OpenBrand sits in the middle: practical enough to use, open enough to own.
Why the MCP and npm versions matter
Hi everyone, I just open sourced OpenBrand - extract any brand's logos, colors, and assets from just a URL.
The dual identity is the point. As an npm package, OpenBrand can live inside a product’s backend with no platform dependency. As an MCP tool, it becomes directly useful to Claude Code, Cursor, and other agentic workflows that need brand context on demand.
That is more than convenience. It makes brand extraction behave like infrastructure. An agent can ask for a brand profile the same way it asks for a file or a schema. That changes where the tool sits in the stack.
Open source alternative, or infrastructure primitive?
| Dimension | OpenBrand | Brand.dev / favicon-only |
|---|---|---|
| License | MIT, inspectable, modifiable | Proprietary or limited |
| Deployment | Self-hostable or API-backed | Usually hosted only |
| Integration | npm package plus MCP server | Platform-specific access |
| Data control | Fits internal tooling and private workflows | Data passes through a vendor boundary |
| Output depth | Logo, colors, imagery, and brand name | Often narrower or opaque |
OpenBrand is not trying to win on novelty. It is trying to make the brand layer portable. That is a sharper proposition than a scraper and a more durable one than a demo.
The bigger pattern is easy to miss. As AI tools spread across product, design, and support workflows, they need more than text. They need to recognize a company’s visual identity quickly and reliably. OpenBrand points toward a future where that capability is a utility layer, not a bespoke integration.
