When your artwork is short of print resolution
A 350 dpi print size is really a pixel count, so convert it first and see how far short your file actually is.
Steps
- Convert the trim size into pixels
Divide each side in millimetres by 25.4 and multiply by 350. That is the pixel count the printer is really asking for. - Compare it with the file you have
Divide the required width by your current width. That ratio, not the dpi field, tells you how much enlargement you need. - Enlarge by the smallest step that clears it
Open Pixmend, use x2 if you are short by a factor of two or less, and x4 only when you are short by more. - Check the linework at 100% before exporting
Look at the thinnest lines and the flat fills at full size, then export as PNG so nothing is re-compressed.
A printer asking for 350 dpi is asking for a pixel count, and the number is fixed the moment the trim size is fixed. Before deciding whether your file can be enlarged into it, work out what "into it" actually means in pixels — then you know whether you are short by a little or by an amount no tool can honestly cover. Open Pixmend once you know which number you are aiming for.
The only calculation involved
Millimetres divided by 25.4, multiplied by 350. Rounded up, the common trim sizes come out like this:
| Trim size | At 350 dpi | With 3 mm bleed on each edge |
|---|---|---|
| A4 (210 × 297 mm) | 2894 × 4093 px | 2977 × 4176 px |
| B5 (182 × 257 mm) | 2508 × 3542 px | 2591 × 3624 px |
| A5 (148 × 210 mm) | 2040 × 2894 px | 2122 × 2977 px |
| B6 (128 × 182 mm) | 1764 × 2508 px | 1847 × 2591 px |
Use the bleed column if your art runs to the edge of the page. The bleed is part of the file you send, so it is part of the resolution you need — which is why a file that looks like it just clears the trim size can still be rejected.
Substitute your own numbers if the specification is different. Some printers ask for 600 dpi on pure black-and-white line art, and a few accept less than 350 for interiors. The specification sheet is the authority; the arithmetic is the same.
dpi is a label, pixels are the thing
A dpi value stored in a file is metadata. Changing a 72 to a 350 in an export dialog adds nothing to the image, and exporting the same file at a higher dpi setting without resampling changes only the number. If your printer's checker rejects the file, it is counting pixels.
This is worth stating plainly because the reverse is also true: a file with the right pixel count is at the right resolution no matter what its dpi field says. If the pixel count in the table above is met, the dpi label can be corrected in seconds.
How much enlargement you actually need
Divide the required width by the width you have. That ratio is the whole decision:
- Short by a factor of two or less — x2 clears it. An A5 page needs 2040 px across, so a 1200 px drawing gets there with room to spare.
- Short by between two and four — x4. A 700 px sketch reaches an A5 page at 2800 px, above the 2040 px required.
- Short by more than four — enlargement is not the answer. Redraw at the target size, or print smaller. A tool that claims otherwise is inventing the difference.
Choose the smallest step that clears the requirement rather than the largest available. On line art, every extra bit of enlargement is another chance for the model to change the character of a stroke. Overshooting the target and scaling back down in your editor is fine, but overshooting for its own sake is not free.
One practical note: x2 and x4 take the same amount of time here, because x2 is produced by running the same x4 model and scaling the output down. Picking x2 is a decision about the result, never about waiting less.
Limits worth knowing before you start
Input images are capped at 12.6MP. A full B5 page held at 350 dpi is inside that, so a finished page scan usually fits, while a large scan of a spread may not. The limit applies to what you put in, not to what comes out.
The first run downloads about 11.6MB of models and runtime, after which they are cached on your device. Nothing else leaves the browser: the image is processed on your own GPU, and you can confirm that in DevTools by watching the Network tab stay silent while the work happens. For an unpublished book, that tends to matter more than any of the arithmetic above.
Before you send the file
Look at the result at 100%, not fitted to the screen, and check the thinnest lines, the ends of strokes, and the flat fills. Then export as PNG so that nothing is re-compressed on the way out — JPEG artefacts that are invisible on screen become visible once ink is involved.
If the source is a JPEG that has already been through a chat app, clean it with a moderate noise setting as it is enlarged, since compression damage enlarges along with everything else. If it came straight out of a paint program as a PNG, there is no noise to remove and the setting should be left alone.
And the honest limit: this repairs what is in the file, it does not draw what is missing. A small, heavily compressed thumbnail has already lost its linework. Made larger, it is the same damaged linework at a larger size — clean enough to look at, not clean enough to print.