The 400% rule: inspecting generated charts and mockups properly

Why a chart that passes at page size fails under magnification, the six details worth checking at 400%, and what zoom can never tell you about the numbers.

ES6 QA AI editorial · 12 November 2026 · 10 min read

Open the tool: Chart detail zoom inspector

Approval happens at the wrong size

A visual is approved in the place it was presented: a slide, a chat window, a preview pane a few hundred pixels wide. At that size every generated chart looks deliberate. The bars line up, the legend has colours, the axis has numbers, and the whole thing reads as a finished piece of design rather than a render.

Magnification is where the fabrication shows. Model-generated text in an image is a shape that resembles letters rather than letters themselves, which is invisible at 30 percent and obvious at 400 percent, where the glyphs dissolve into soft blocks and half-formed characters. The same happens to tick marks, gridlines, footnotes and anything the model drew by inference rather than by measurement.

This is not pedantry about image quality. It is the inspection the audience performs for free. A reader pinches to zoom on a phone, uses browser zoom on a laptop, or passes a printed handout around a meeting. Every one of those actions exposes detail that looked fine in the preview, and the reader who finds a garbled axis label does not conclude that one label is broken. They conclude that nobody checked.

Work the numbers before the letterforms

Start with the axis, because that is where a chart can be structurally wrong rather than merely ugly. Labels should count in order, at consistent intervals, and stop where the scale stops. A y-axis that runs 0, 20, 40, 80 is a chart with a hidden gap, and a bar chart whose baseline is not zero is a chart that exaggerates.

Then check units. Units are the first thing a generated image loses, because a unit is a small piece of meaning in a small piece of space. Look for a stray percent sign floating above a tick, a currency symbol that appears once at the top of an axis, a thousand-separator in a number that should not have one.

Then read the legend against the plotted series. A five-item key over three lines is decoration rather than a legend, and it is common: the model generates the furniture of a chart without the arithmetic that would require it. The same applies to annotated callouts that point at nothing, and to gridlines that fail to intersect their labels.

Finally, read the smallest type you can find. Callouts, source lines, the copy printed on a product mockup. Letters should be whole shapes with no two glyphs fused, and the words should be words rather than plausible-looking consonant clusters.

  • Axis labels in order, at even intervals, ending where the scale ends.
  • Baseline at zero for any bar comparison.
  • Units attached to numbers rather than floating near them.
  • Legend items matched one to one with plotted series.
  • Callouts pointing at something, with text that resolves at full zoom.
  • Small type legible: no fused glyphs, no invented words.

The checks that end in a verdict

Reading a visual without recording anything produces an impression, and impressions do not survive a handoff. A structured checklist turns the pass into something a second person can repeat and a client can read: each item is marked pass or flagged, and the asset closes with a stated result rather than a feeling.

The value of that structure is that it stops you from stopping early. It is easy to look at the headline number, decide the chart is fine and move on; it is harder to leave a check unflagged when it is sitting in a list in front of you.

Keep the flags specific. Not axis problem but left axis skips 60, not smudged text but legend label at 62px is illegible. A specific flag can be fixed by someone else; a general one has to be re-diagnosed before it can be fixed.

For a batch of assets, the same checklist applies to each one, which is the other reason to have it: consistency across ten charts matters more than perfection on one.

Infographics, dashboards and diagrams

A chart has one axis to check; an infographic has a canvas. The inspection widens with the form: icons that mean one thing in the key and something else in the body, arrows that point at nothing, a numbered sequence that skips four, a timeline whose labels crowd into each other at the right-hand edge.

Generated dashboards are the richest source of this class of failure, because a dashboard is mostly furniture. Filters with no effect, a sidebar of labels that names sections the page does not contain, a card with a KPI and a sparkline whose shape has no relationship to the number above it. At a glance it reads as a product; zoomed, it is a picture of a product.

Diagrams and maps fail differently. A flowchart with two arrows leaving one decision and no labels, a network map whose lines cross through the boxes they connect, a map with a coastline that does not exist or a city label placed in the sea. Those are worth inspecting at 400 percent specifically, because the geography and the topology are the content.

Ask one question of any generated interface image: could somebody rebuild this screen from the picture, or is it only a resemblance? If a control has no visible input, or a list has no items, or a chart has no data source, the image is decoration and should be used as decoration rather than as a screenshot of a product.

Recording a verdict somebody else can use

A pass that ends in a feeling produces another pass tomorrow. A pass that ends in six recorded outcomes produces a decision: ship it, fix three things, regenerate. The checklist is short enough to complete honestly and specific enough to be acted on by somebody who was not in the room.

Keep flags specific and located. Left axis skips 60, legend item four has no matching series, product label illegible at 2400px: each is a fix. Bad axis, bad legend, bad text is a conversation.

Record what passed as well, sparingly. A note that says five of six checks passed and names the sixth is more useful than a list of six passes, and much more useful than a verdict with no detail behind it.

Then close the loop with the person who made the asset. A designer who receives a specific, reproducible finding fixes it once; one who receives the impression that something looks off will produce a variation and hope, which is how the same defect returns in the next export.

Coordinating with whoever made the asset

The output of a visual inspection is a brief, not a verdict. A list of six specific findings is something a designer, a generator or a freelancer can act on; a note that says it does not look right is a conversation that will take three rounds and end in a variation nobody checked.

Group the findings by cost. Text legibility is usually a re-render; an axis that skips a value is usually a data problem upstream; a legend that names an unplotted series is a generation that has to be redone. Sending them in one list hides that difference and makes the whole asset look like a redo.

Say what passed. A designer who receives five findings and no sense of what is fine will redo the parts that were already correct, and the second version will introduce two new defects in exchange for the five.

The three assets people forget to inspect

Social cards, app store screenshots and email headers are generated as often as charts and rarely inspected, because nobody looks at their own preview twice. Each has a constrained frame, a required legibility standard at a small size, and a habit of being rebuilt by the platform on upload.

Check them at the size they will actually be seen. A card that reads beautifully at 1200 pixels becomes four illegible words at thumbnail width, and an app screenshot whose device frame is slightly wrong is the first thing a reviewer notices and the last thing anyone checked.

Exports, retina files and the size you inspect

Inspect the file at its published dimensions, not at the size it happens to open. A two-times export displayed at half width loses the very softness you are looking for, and a chart exported at print resolution will pass checks that the web version cannot.

Where both exist, check the smaller one. It is the version readers will see, it has been through more compression, and it is the file that decides whether the labels survive on a phone.

What magnification cannot see

A chart can be immaculate and plot numbers nobody measured. Zoom proves legibility and structural integrity; it says nothing about accuracy, and an AI-generated chart with invented data is usually more convincing when it is well rendered, not less.

If the figures matter, they have to go somewhere that checks them. That means a claim ledger where each number carries a status and a source, or a comparison against the dataset the chart claims to summarise. The zoom inspector can tell you the axis is coherent; only a source can tell you the axis is honest.

The same boundary applies to product mockups. Crisp edges, correct perspective and legible packaging copy do not mean the product in the image is the product in the box. An image that has been re-rendered from a description will faithfully reproduce the description, including the parts the description got wrong.

And for anything depicting a real person, a real event or a specific capability, legibility is not the question. Disclosure is. The visual can pass every check on this list and still need a caption saying how it was made, and that decision belongs to whoever publishes it.

These rules are the same ones the console runs. Check a file against them now.

Start with one file

Find out what your AI output is hiding.

The console is free, needs no account and uploads nothing. See the findings first, then decide whether you want a specialist to sign it off.