← All posts

You chose greyscale and it still printed in colour

You ticked "Print in greyscale (black and white)". You went into the driver and set colour mode to mono. The page came out with colour on it anyway — or it came out grey and the meter still counted a colour click, which at 8p a page instead of 1p is the same problem with a bigger number attached.

This is one of the most persistently unanswered questions in printing. The top two results for it are Adobe forum threads, and the busiest one is still open: the last suggestion was "change the driver default", nobody confirmed it worked, and that was that.

The reason it keeps going unanswered is that there are two separate failures wearing the same costume, and the advice for one does nothing for the other.

Why the greyscale tick box often does nothing

Your greyscale setting is not a property of the document. It is a request, and it has to survive four handovers before any toner moves:

  1. The application. Acrobat's "Print in grayscale" applies to what Acrobat draws. With some drivers it hands the PDF over whole and lets the printer render it, and the checkbox never reaches the page.
  2. The driver, for this job. The Properties or Preferences button in the print dialog. This is the setting most people change, and it lasts exactly one job.
  3. The driver default, at OS level. What every job gets when nothing else says otherwise — including jobs launched by something that never shows you a print dialog.
  4. The printer itself, and the queue it sits behind. The front panel has a colour mode. A shared or managed printer usually has a server-side configuration that is pushed to your machine and quietly replaces whatever you set.

Each layer can override the one above it. So the fix that works on your desk on Tuesday stops working when the print server re-applies its policy on Wednesday, and the person telling you it works for them is standing at a different point in the chain.

Why a page that looks black and white is still a colour job

The second failure is different, and it is the one that produces a bill rather than a coloured page.

Most printers and nearly all copier fleets decide colour versus mono per page, automatically, by inspecting what the page contains. That check is cheap and crude: if anything on the page is defined in a colour space that is not grey, the page is a colour page. It does not care whether you can see the colour.

Things that trip it constantly:

The device then prints the page in colour mode, converts it to grey on the way out, gives you a grey sheet, and records a colour click. Grey output, colour billing. Nothing in your print dialog changed what was in the file.

Rich black, and why your black text prints with cyan in it

The specific version of this that catches people out: black text that arrives with a blue or brown cast, on a printer that is supposed to be in mono.

Black comes in two forms. K-only black is one ink: C0 M0 Y0 K100. Rich black is black built from all four inks — a designer adds cyan and magenta under the K to make large solid areas look deeper, and it is standard practice in print design. RGB black gets you there by accident too: when 0,0,0 is converted to CMYK through a colour profile, the ordinary result is a four-ink composite black unless black preservation is switched on.

Either way the page now needs all four inks to render its text, so it is a colour page and it prints like one. This is why the text looks slightly wrong as well as costing more.

Take the colour out of the file, so no driver can put it back

The setting is fought over by four layers. The file is not. If the document itself contains no colour anywhere, there is nothing for auto-detection to find and nothing for a policy to override.

  1. Keep the original. This matters more than it sounds — see the warning below. Put a copy somewhere before you touch anything.
  2. Run it through Greyscale PDF. Every page is redrawn at 150 dpi as an 8-bit grey picture and that picture becomes the page. There is nothing to configure. It does not try to find and rewrite the colour instructions, because that approach reaches only the colours a page states directly and misses colour inside images, shadings and transparency groups — which leaves a document that is almost grey, the one outcome that gets you billed anyway.
  3. Look at the result before you print it. Pale yellow highlighting becomes pale grey, not nothing. Coloured text that stood out against its background may now be the same tone as it. A chart whose series were told apart by colour may have become unreadable.
  4. Print from the converted copy, and set the driver to mono as well. Belt and braces: the file handles the automatic page count, the driver setting handles the engine.
  5. Print one page first if you are being charged, and check what the meter recorded before you send four hundred.

If you need the text kept, use Ghostscript

Rasterising is the reliable answer, not the only one, and it is the wrong answer if the document has to stay searchable or accessible. The free tool that does the other kind of conversion — rewriting the colour while leaving the text as text — is Ghostscript:

gs -sDEVICE=pdfwrite -sColorConversionStrategy=Gray \
   -dProcessColorModel=/DeviceGray -dOverrideICC \
   -o out.pdf in.pdf

That converts colour spaces rather than pixels, so the text layer survives. It can still leave colour inside some embedded objects, which is exactly the trade we chose to avoid, so check the result if a colour count is the thing you are trying to beat. Acrobat Pro's Convert Colors does the same job with a preview, if you have it.

Checking a file before you send it

Ghostscript will also tell you which pages carry colour, which is the number you want when a print shop bills per colour page:

gs -o - -sDEVICE=inkcov in.pdf

It prints four coverage figures per page. Where the first three are 0.00000 the page is K-only. Anything else on those three is a colour page in the eyes of the machine.

Our PDF inspector does not report colour — worth saying plainly. It reads page count, page sizes, the PDF version, encryption, tagging and whether there is a real text layer, all in your browser. Useful for working out what you are dealing with, not for this particular question.

What this will not do

It will not change how a print shop bills you. It removes every trace of colour from the file, which is what an automatic count looks for, but shops measure differently. If the difference is large, send one converted page and ask them to confirm the rate before you commit.

It is greyscale, not black and white. There are 256 levels of grey and nothing is thresholded. If you want stark black-on-white, this is not the tool.

150 dpi is a printing resolution, not an archival one. Body text on A4 is fine. Fine line art, small maps and anything going out at A3 or larger will look soft. For those, render the pages yourself at 300 or 400 dpi with PDF to JPG, then rebuild with JPG to PDF — more steps, sharper result, still no text layer.

There is no per-page option. Every page goes grey. If only some pages need it, split the document, convert that part and merge it back.

It does not fix the printer. The next document you open prints under the same settings. If you want mono to be the default, set it in the OS: on Windows, Settings → Printers → your printer → Printing preferences (not Print dialog properties, which is per-job); on macOS, print any document, choose the mono setting, then save the whole lot as a preset and set that preset as the default.

When the file has grown and it has to go by email

A greyscale conversion often doubles the size of a text document, for the reason in the caveat. Run it through Compress PDF afterwards. Expect a decent reduction, because the file is now nothing but images and images are what compression works on — the opposite of the case where a PDF refuses to get any smaller, which is a file that was already mostly text.

Managed printers, where none of this is yours to change

If you are on an office fleet, the driver defaults are pushed from a print server and your local changes are reverted at the next policy refresh. Some fleets go further and hold the colour decision entirely at the device, keyed to your user account. Nothing you set on your machine survives that.

Which is the argument for fixing the document rather than the settings. A file with no colour in it prints the same way on every printer, in every building, under every policy, and next month as well as today.

Tools this post uses: