What your journal checks, and what it does not
Two publishers, the same 300 dpi, and only one of them asks whether anyone can tell your colours apart.
You are a few days from submitting. You open the author guidelines, find the figure section, and it tells you 300 dpi, TIFF, and a width in millimetres. You make your figures 300 dpi, TIFF, and that width. You have now met every requirement your journal stated, and you have no idea whether your figures work.
That is not a criticism of you. It is a description of the lists. They are production specifications, written so the typesetter’s software does not choke, and they have been mistaken for a standard of quality because they are the only written thing anybody hands you.
Here is what two large open-access publishers ask for. Both were read from the publishers’ own pages on 7 September 2026, and both are quoted rather than summarised, because the pages that rank for these searches are mostly written by companies selling figure software and their numbers are not reliable.
The same resolution, a different idea of a figure
PLOS ONE wants 789 to 2250 pixels wide at 300 dpi, which it also gives as 6.68 to 19.05 cm. TIFF or EPS, nothing else. 300 to 600 dpi. Text in Arial, Times or Symbol only, at 8 to 12 point. Under 10 MB, LZW compressed, flattened, no alpha channel.
Frontiers wants 300 dpi at final size, one column at 85 mm or two at 180 mm, TIFF or JPEG or EPS. The smallest visible text no less than eight points when viewed at actual size. No line thinner than two points. It warns you off red and green as your two indicators, notes that more than 99% of colour-blind readers have a red-green deficiency, and asks you to carry the distinction in shape, labels or size as well as colour. It then gives contrast ratios: 4.5:1 for level AA, 7:1 for AAA.
Read those twice. Both demand 300 dpi. One of them tells you which three fonts you may use and says nothing whatsoever about colour. The other tells you the contrast ratio your figure has to reach.
The requirements you are handed are not a standard. They are a local dialect, and the parts that decide whether your figure can actually be read are the parts most journals leave out.
Three things that go wrong, at the size they go wrong
Every specification below is stated at final size, and that phrase is doing almost all of the work. A figure is not published at the size you drew it.
Your type is not the size you set it
Frontiers asks for eight points minimum at actual size. If you build a figure at the two-column width and it runs at one column, everything in it is multiplied by 85/180, which is 0.47.
Label type, at the size it will be printed
Set at true physical size. The eight point minimum is the line to clear after reduction, not before it. A twelve point label drawn for the two-column width lands below the minimum when the figure runs at one column.
The fix costs nothing and almost nobody does it: decide the column width before you draw, and set the type in the figure so it is right at that width. Drawing large and letting the journal shrink it is the single most common way a perfectly good figure arrives illegible.
Your lines are thinner than the minimum
Frontiers will not take a line under two points. That is thicker than it sounds, and it is very likely thicker than what your tool gave you. Observable Plot, which draws every chart on this site, defaults to a stroke of one pixel, which is 0.75 point: we checked our own tool rather than assume, and it comes in at a little over a third of the minimum. Check yours the same way, in whatever units it reports, before you take a default on trust.
Stroke weights, at the size they will be printed
At true physical size. The default weight in most charting tools is around three quarters of a point, which is roughly a third of the minimum Frontiers will accept, and the thinnest rules here are the ones that disappear when a figure is printed rather than viewed.
Your two colours may be one colour
This is the one that no production specification catches, and it is the one that costs a reader the result.
Take a mid red and a mid green, the pair any tool will hand you for two conditions. In ordinary vision they are far apart: 33.8 on the same OKLab scale this site uses to screen its own palettes, where anything below about ten is where two series stop being reliably distinguishable. Under simulated deuteranopia, the most common form of colour blindness, the same two colours fall to 4.1.
A red and a green, and the same pair as a deuteranopic reader sees them
Simulation after Machado, Oliveira and Fernandes (2009) at full severity, using the same code that screens this site's own palettes. The pair separates by 33.8 in ordinary vision and by 4.1 under deuteranopia, against a floor of 9.5 that this site holds its own six colours to. A figure using these two colours meets every specification PLOS ONE states.
Nothing in the PLOS ONE figure specification would stop that figure. It can be a 300 dpi TIFF, 19 cm wide, set in 9 point Arial, under 10 MB, and every stated requirement is met. Roughly one man in twelve cannot read it.
What to do instead
The production specification is a floor, and you should meet it. Then check the four things it does not ask about.
- Decide the column width first, and set your type so it clears eight points at that width, not before reduction.
- Thicken your strokes. Whatever your tool gave you, it is probably a third of what a printer wants.
- Never let colour be the only difference between two series. Shape, dash pattern or a direct label costs you nothing and survives both colour blindness and a photocopier.
- Export vector where the figure is drawn rather than photographed. A plot is lines and text, and dpi is meaningless for it. Rasterising a chart to hit a dpi number throws away the thing that made it sharp.
None of that is in most author guidelines. All of it is what an editor notices.
The four checks above, and the twenty-two that go with them, are on one page at the pre-submission figure checklist, which you can print and keep beside you while you build the figures. It is free and there is no email wall.