A logo gets a lot of help in a large preview. There's room for the lettering, the background suits the colors, and every small detail has enough pixels to exist.
Put the same file in a browser tab and things get less forgiving.
The name turns into a smudge. A thin line disappears. Switch to a dark theme and half the mark goes with it.
We're building DepthLogo, an AI logo generator with a logo editor. One part of the product is a browser-based logo checker. It looks at the practical side of a logo file: transparency, resolution, how it holds up at small sizes, and how it behaves against different backgrounds.
That gives us a useful engineering problem to work on: what can a tool tell you about a file without pretending it can judge the entire design?
Start with the space the logo will occupy
A 2000px image can be a poor favicon. More source pixels won't make an eight-letter name readable inside a 16px square.
Consider a wordmark that's six times wider than it is tall. Fit it into a 32px square without cropping, and the artwork gets roughly five pixels of height. That's before any padding already present in the file.
The browser hasn't done anything wrong. The asset doesn't suit the slot.
You can catch quite a lot with a tiny test page. Put your own file at /logo.png and render it at the sizes you intend to use:
<div class="logo-preview">
<img src="/logo.png" width="16" height="16" alt="Logo at 16px">
<img src="/logo.png" width="32" height="32" alt="Logo at 32px">
</div>
<div class="logo-preview logo-preview--dark">
<img src="/logo.png" width="16" height="16" alt="Logo at 16px on dark">
<img src="/logo.png" width="32" height="32" alt="Logo at 32px on dark">
</div>
.logo-preview {
display: flex;
align-items: center;
gap: 24px;
padding: 24px;
background: #fff;
}
.logo-preview--dark {
background: #0f172a;
}
.logo-preview img {
display: block;
object-fit: contain;
}
object-fit: contain keeps the image's proportions inside each square. It also keeps any empty space baked into the image. A 512px canvas with a small symbol in the middle still produces a small symbol.
Look at these previews at normal page zoom. Enlarging them is useful for debugging the pixels, but it changes the question. You're trying to find out whether someone can recognize the mark while looking for a tab.
Sometimes the right fix is a separate icon: the symbol alone, or a single letter. You can keep the full wordmark in the header.
PNG tells you the format, not the background
A white logo preview on a white page can hide an opaque white rectangle surprisingly well.
PNG supports transparency. That doesn't mean a particular PNG contains it. A gray checkerboard can even be painted into the image, so the familiar transparency pattern becomes part of the artwork.
For a pixel-based check, you need to inspect alpha as well as color. The browser's Canvas API exposes image pixels through getImageData(), which makes that kind of inspection possible locally.
There is a catch: finding a few partly transparent pixels doesn't prove the background is transparent. They might just be softened edges around an otherwise opaque image. Even a fully transparent pixel somewhere in the file says little about the rest of its background.
A visual check still helps. Place the image against white, a dark color, and a color you wouldn't normally choose for the brand. The awkward background is useful because it makes boxes and pale fringes easier to spot.
Also, a transparent background doesn't guarantee the logo will work in dark mode. A dark symbol can have completely correct transparency and still disappear against a dark header. That needs a light version of the mark, or an intentional background behind it.
Those are different problems, so the report should explain them separately.
An SVG can still contain a bitmap
The .svg extension isn't a promise that every part of the artwork is vector geometry.
SVG has an <image> element, and that element can contain raster artwork. This is valid SVG:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512">
<image href="logo.png" width="512" height="512" />
</svg>
The document scales. The PNG inside it still has a fixed number of pixels. Putting it inside an SVG doesn't turn those pixels into paths.
That matters when someone expects to use the file for a large sign or send editable artwork to a designer.
Finding an <image> element is a reason to inspect the file, though. It isn't a reason to reject every SVG that contains one. An SVG can legitimately combine vector shapes with a raster texture, and an image element can reference another SVG.
The useful question is whether the artwork provides what the person needs. If they asked for a scalable vector mark and received only a wrapped PNG, the file hasn't met that requirement.
Even paths don't solve the favicon problem from earlier. Vector geometry can scale down cleanly while becoming too small to recognize. File structure and small-size legibility need separate checks.
This part can stay in the browser
For DepthLogo's checker, the selected logo file stays on the user's device. The file inspection runs in the browser.
That's a good fit for this particular job. Reading image dimensions, looking at pixels, and showing background previews don't inherently require a server upload. Someone checking an unreleased brand can use the tool without sending us the artwork.
I wouldn't apply that decision to every image-processing feature. Large files and expensive operations need their own performance budget. But for a focused file checker, local processing is worth considering before adding an upload endpoint.
It also helps to keep the analysis separate from the interface. Small test images can isolate specific cases: a dark shape on transparency, a colored shape in a white box, or fine lines that stop surviving at small sizes. You can test the expected warning without making the entire page part of the test.
A nice-looking result screen won't tell you whether the checker can distinguish those cases.
A warning needs a next step
The difficult part of a checker is deciding what its findings mean to the person using it.
A wide wordmark might be exactly right for a website header. Warning about its proportions only helps if you explain that it will be hard to use in a square avatar. Otherwise, the tool is criticizing a design for a job it wasn't meant to do.
The same goes for a detailed, shaded logo. It may work well on a large landing page and need a simpler companion for the browser tab.
A useful report can say, “Keep this version for the header; use the symbol on its own for the favicon.” That gives someone a task they can finish. A lower score on its own mostly gives them something to worry about.
That's the role we give the logo checker: help people spot file and usage problems before they place the logo everywhere. It doesn't decide whether their brand is good, or whether the mark is legally available.
If you're adding a logo to a project, try the small previews before spending time on the large one. Getting the file into an <img> tag is easy. Making sure it still does its job there takes a closer look.
Top comments (0)