The Car Logo Problem Every Automotive Dev Team Has (And How to Fix It)

Adrian — Thu, 16 Apr 2026 12:54:47 +0000

You know the folder. Every automotive project has one.

/public/logos/
  toyota.png
  honda.png
  ford.png
  kia.png          ← this one's wrong
  kia-new.png      ← is this the right one?
  kia_2021.png     ← wait, which one do we actually use?
  peugeot.png      ← spoiler: also wrong
  ...
  misc/
    bmw_old.png
    bmw_new.png
    bmw_USE_THIS_ONE.png

If you've built anything in the automotive space — a car marketplace, a dealer platform, a fleet tool, an insurance comparison app — you've been here. The logo folder starts small and reasonable. Then a brand refreshes their identity, a PM notices the wrong logo on production, and suddenly you're deep in a Wikipedia rabbit hole trying to find an SVG that doesn't look like it was exported from 2007.

This is the car logo problem. It's mundane, it's unglamorous, and it quietly costs dev teams real hours. Let me walk through why it's worse than it sounds, and what actually fixes it.

Why "Just Grab the Logo" Is Never Simple

On the surface it seems trivial. Download a PNG, drop it in /public, done. But here's what actually happens in practice:

Quality is all over the place. Official brand websites don't always have clean, developer-ready assets. You end up on third-party logo sites with watermarks, inconsistent backgrounds, and resolutions that are either way too small or absurdly large.

You need multiple variants. Most UIs need more than one form of a logo. A full horizontal lockup for a detail page, a badge/emblem for compact list views, a wordmark-only for a certain layout breakpoint. For 50 brands, that's potentially 150 files to source, name consistently, and maintain.

Brands rebrand. Constantly.

This one is the real killer. In the last five years alone:

Kia (2021): Complete identity overhaul. The old interlocking KIA is gone, replaced with a bold angular mark that looks nothing like the old one.
Peugeot (2021): Went from a traditional lion badge to a flat, shield-based emblem.
GM (2021): Quietly updated their corporate logo.
Nissan (2020): Moved from a 3D chrome badge to a flat, minimalist redesign.
BMW (2020): Flattened their roundel for digital use.
VW (2019): Major simplification before the ID.4 launch era.
Toyota (2023): Updated global brand guidelines.

If you're serving 400+ brands and seven of them rebrand in five years, that's seven fires — minimum. Now multiply by the number of apps and teams affected.

I've seen the Slack message: "Hey, who has the new Kia logo? The one on the listing page still shows the old one." That message has been sent at hundreds of companies.

The Stopgap Approaches (And Why They Fail)

Before getting to the fix, let's acknowledge the workarounds, because you've probably tried them.

Wikipedia Commons / brand press kits: Hit or miss on format, always manual, often legally ambiguous.

Scraping brand websites: Fragile. Breaks when they update their site. Also definitely against their ToS.

A shared Dropbox/Drive folder: Works until the person who maintained it leaves the company. Then it's archaeology.

Outsourcing it to the design team: They have other things to do. This becomes a bottleneck or gets deprioritized until someone complains about a wrong logo on a listing that's been live for 18 months.

The pattern is always the same: manual, brittle, and it falls on whoever cares most in the moment.

There's a Dedicated API for This

I built Motomarks as a better solution for a vehicle comparison tool. The pitch is simple: it's a car logo API — a CDN-backed service that serves manufacturer logos for 420+ automotive brands, keeps them updated when brands rebrand, and lets you drop an <img> tag in instead of managing a file system.

Here's the simplest possible integration:

<img
  src="https://img.motomarks.io/toyota?token=YOUR_KEY"
  alt="Toyota logo"
/>

That's it. You get back the logo, optimized for the browser. No folder. No filename convention debates. No "which version is current" ambiguity.

What You're Actually Getting

The API serves logos in three formats:

Full logo — the complete brand mark, however the manufacturer uses it
Badge / emblem — the icon/symbol only (useful for compact UIs, table rows, map pins)
Wordmark — the text-only version

Six size tiers (XS through XL), and automatic format selection between PNG, WebP, and AVIF based on what the browser supports. The CDN has 700+ edge locations globally, so you're looking at sub-millisecond response times in practice, with a 99.99% uptime SLA.

The part that actually matters for the rebrand problem: they maintain the assets. When Kia updates their logo, you don't touch your code. The slug stays kia, the URL stays the same, the image updates. Your app gets the new logo without a deploy.

React / Next.js Integration

For a Next.js app, you'd typically store the token in an environment variable and use it with the Image component:

// components/BrandLogo.jsx
import Image from 'next/image'

const MOTOMARKS_BASE = 'https://img.motomarks.io'

export function BrandLogo({ slug, alt, size = 'md' }) {
  const src = `${MOTOMARKS_BASE}/${slug}?token=${process.env.NEXT_PUBLIC_MOTOMARKS_KEY}&size=${size}`

  return (
    <Image
      src={src}
      alt={alt || `${slug} logo`}
      width={120}
      height={60}
      style={{ objectFit: 'contain' }}
    />
  )
}

Then wherever you're rendering vehicle listings:

// In your vehicle listing component
import { BrandLogo } from '@/components/BrandLogo'

export function VehicleCard({ vehicle }) {
  return (
    <div className="vehicle-card">
      <BrandLogo
        slug={vehicle.make.toLowerCase()}
        alt={`${vehicle.make} logo`}
        size="sm"
      />
      <h3>{vehicle.year} {vehicle.make} {vehicle.model}</h3>
    </div>
  )
}

The slug is just the brand name lowercased. The API returns JSON metadata if you need it — useful if you want to build a brand directory or display brand names consistently:

// Fetch metadata for a brand
const res = await fetch(
  `https://api.motomarks.io/brands/bmw?token=${process.env.MOTOMARKS_KEY}`
)
const brand = await res.json()
// { id: "bmw", name: "BMW", country: "DE", founded: 1916, ... }

There's also a TypeScript SDK if you want typed access instead of raw fetch calls.

The Free Tier

Worth mentioning: there's a free tier with 1,000 requests/day. For a lot of internal tools, dashboards, or low-traffic sites, that's enough to validate the integration before committing. It requires attribution (reasonable), and you get the same CDN and format optimization as paid tiers.

For context on what 1,000 requests/day means in practice — if you're lazy-loading logos on page views and a user visits a 10-brand comparison page, that's 10 requests. So 100 visits/day before you hit the limit. Small apps and prototypes fit comfortably.

When This Actually Makes Sense to Use

Motomarks is a good fit if you're building:

Car marketplaces or classifieds — you're rendering dozens of brand logos per page, across hundreds of makes
Dealership websites — need consistent, current logos for every brand in inventory
Fleet management tools — mixed fleet dashboards with 20+ manufacturers
Insurance or finance apps — comparisons and quotes that display vehicle brand identity
Vehicle databases or lookup tools — anywhere brand identity is part of the data presentation

It's less useful if you're dealing with just 3-5 brands that never change — at that scale, a static folder is fine and the overhead isn't worth it.

The Real Value Proposition

The time savings aren't in the initial setup — dropping an <img> tag in takes about the same time as downloading a file. The savings come later, when Peugeot or Kia or whoever is next rolls out a new identity and your app just... handles it. No ticket, no Slack thread, no weekend deploy.

If you're working on anything automotive, it's worth a look: motomarks.io. The free tier is enough to wire up a prototype and see if it fits your architecture.

Have you dealt with the logo folder problem on a project? I'm curious how other teams have handled it — drop a comment below.

DEV Community: Adrian