The pixel size of a stamp in a document, and the one check before you send it

Someone asks for "a stamp for our invoices", you make one, you send the PNG, and it comes back looking soft and slightly too big. You export it again, larger. Now it is sharp and much too big. Somewhere in there is a number nobody tells you.

The number is not a stamp thing. It is the same arithmetic behind every image that has to land at a known physical size in a document.

The one line

pixels = millimetres / 25.4 * dpi

An inch is defined as exactly 25.4 mm, so this is not an estimate. A 35 mm round stamp at 220 dpi is 35 / 25.4 * 220 = 303 px. At 96 dpi the same stamp is 132 px. Same stamp, same document, two files that differ by a factor of 2.3 — and the only thing that changed was where it was going.

Where the dpi number comes from, and where it does not

This is the part I got wrong for a while, so it is worth being precise about what is documented and what is convention.

Documented: Microsoft Office has a default-resolution setting for pictures you insert, with options at 96, 150, 220 and 330 ppi plus "High fidelity". Those numbers are real and they are Microsoft's. What they are for is compression of images you paste in — they are not a statement about what your artwork must be.

Convention, not spec: 300 ppi for anything going to a printer. Widely recommended, including by commercial printers, but it is a convention rather than a format requirement.

Neither: any per-destination table you find that says "Google Docs needs exactly X". I have not found a source for that, and I would treat one with suspicion. What you can say honestly is that a document read on screen needs far fewer pixels than the same document printed, and picking a number in the 150 region for screen-first and 300 for print-first will not embarrass you.

So: treat the presets as reasonable starting points with an honest provenance, not as requirements. The arithmetic is exact. The dpi you feed it is a judgement call.

The failure that actually costs you the job

Not size. Background.

A stamp is supposed to sit over text. If the file has an opaque white rectangle behind the ink, it covers whatever it lands on, and the person who receives it will describe this as "it looks wrong" rather than "your alpha channel is missing". Two ways this happens:

1. The export never had transparency — a JPEG, for instance, which has no alpha channel at all. There is no fixing this after the fact; it has to be re-exported.
2. The export has an alpha channel, but the artwork was drawn on a white fill. Technically transparent, visually a white box.

A cheap check: look at the pixels around the border of the image. If they are fully transparent, the edge is clean. If they are opaque white, you have a box. This does not prove anything about the middle of the image — a white rectangle with a one-pixel transparent border will pass an edge check and still be a white rectangle — so treat it as a fast negative test, not a certificate.

Worth knowing: partially transparent is its own trap. Alpha 249 out of 255 is 98% opaque, and it will look like a faint white box rather than no box. "Has some transparency" and "has a transparent background" are different claims.

PNG or SVG

If the destination will only accept a raster image, PNG, sized with the line above. If it will take vector, SVG, and then the whole question disappears — the renderer resolves it at whatever the output device needs.

The reason to keep an SVG even when you deliver a PNG is that it stays editable. A year later, when the company name changes, you can fix the file instead of rebuilding it.

Tools

I maintain a couple of browser-side tools for this, both free and neither needing an account:

• a stamp maker that sizes the export for its destination — draw it, enter the physical size and the target, and the PNG downloads at the computed width rather than at some fixed default. It also does the edge check described above.
• a date stamp generator, if what you need is a dater face. That one has a different trap in it: 03/04/2026 is two different days depending on who picks up the paper, which is 132 ambiguous days a year.

Everything runs in the page; no upload is involved either way.

The short version

Compute the pixels instead of guessing, be honest that the dpi figure is a judgement rather than a spec, and check the border pixels before you send the file. That is most of it.