ForHosting KIT · Documents & PDF

Convert PDF to grayscale

Four pages marked color, grayscale, CMYK and grayscale come back as four grayscale pages, with a count showing that 2 of them actually needed a change. Use it to plan a conversion or spot mixed files before rendering. Free in your browser.

  • Free
  • Runs in your browser
  • No sign-up
  • Your data stays on your device
Use it from WebAPIEmailTelegramApp soon
If you enter
Pages
color, grayscale, CMYK, grayscale
You get
Pages
grayscale, grayscale, grayscale, grayscale
Page count
4
Pages changed
2

Convert a PDF to grayscale at the page-metadata stage with a small, deterministic operation. Provide the current color mode for every page in document order, and the capability returns a matching list in which every page is marked as grayscale. It also reports the total page count and exactly how many page modes changed, distinguishing a complete conversion from a request whose pages were already grayscale. Empty documents are rejected with a clear input error.

Represent the PDF as ordered page modes

This capability works with the per-page color-mode information produced by a PDF inspection or processing step. Supply one non-empty mode string for each page, keeping the strings in the same order as the pages in the document. For example, a three-page PDF might be represented as color, grayscale, and cmyk.

The output has three entries in the same order, with each entry set to grayscale. Because the operation acts on page descriptors rather than uploaded binary data, it is predictable, fast, and easy to place between PDF analysis and a later rendering or export stage. The input must contain at least one page.

A missing pages field, an empty list, a non-list value, or an empty mode string is rejected instead of being treated as a successful zero-page document. That strict behavior keeps pipeline mistakes visible and prevents an absent parser result from looking like a valid conversion. The page order is never sorted, deduplicated, or otherwise changed.

Use the result in a PDF processing workflow

The result is designed for workflows that separate PDF inspection, transformation planning, and file rendering. First, a parser or document system determines the current mode of each page. Next, this capability normalizes the plan and reports how many page descriptors require a change.

The count can support a preview such as “12 of 30 pages will change,” verify that a supposedly converted document no longer contains color modes, or flag unexpected mixed-mode source files.

Prepare a conversion plan

Normalize inspected page modes before sending an ordered grayscale target list to a PDF rendering stage.

Audit mixed-mode documents

Count how many pages in an incoming PDF are not already marked as grayscale.

Verify an upstream conversion

Confirm that a processed document reports zero remaining page-mode changes without accepting an empty result.

Does this return a converted PDF file?

No. It normalizes supplied per-page color-mode descriptors. A downstream PDF renderer must apply the requested mode to document pixels and resources.

Does page order change?

No. The returned pages array has exactly the same length and order as the input array.

Does a page written as GRAYSCALE or with extra spaces count as changed?

No. Capital letters and spaces around the value are ignored, so those pages are recognized as already grayscale. Only modes such as color, rgb, cmyk or monochrome are counted as changed.

What does a result of zero changed pages mean?

It means the list was valid and every page was already grayscale, so nothing needed a change. It never means the document was empty: an empty list is rejected with a clear message instead.

How can I use the count of changed pages?

Show a preview such as 12 of 30 pages will change, confirm that an already converted document has no color pages left, or flag incoming files that mix color and grayscale pages.

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

POSThttps://api.kit.forhosting.com/pdf/grayscale

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

curl -X POST https://api.kit.forhosting.com/pdf/grayscale \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"pages":["color","grayscale","cmyk"]}'
{
  "pages": [
    "color",
    "grayscale",
    "cmyk"
  ]
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "pdf.grayscale",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

max_mb25
max_pages200
HTTPCodeMeaning
401unauthorizedMissing or invalid API key.
402insufficient_balanceYour balance doesn't cover the task price.
404unknown_typeThat task type doesn't exist.
429rate_limitedToo many requests. Use the webhook instead of polling.

Understand the changed-page count

Every valid input entry becomes the exact canonical value grayscale. Values between those limits identify mixed-mode documents. The pages_changed field counts only page modes whose trimmed, case-insensitive value was not already grayscale. Therefore, grayscale, GRAYSCALE, and a value surrounded by harmless whitespace are recognized as already grayscale, while color, rgb, cmyk, monochrome, or another non-empty mode is counted as changed. This distinction is useful when conversion work has already happened upstream or when mixed documents arrive from several sources. The page_count field always equals the number of supplied entries, and the returned pages array always has that same length. A result with pages_changed equal to zero means the request was valid but no page needed a mode change; it does not mean the input was empty. A result equal to page_count means every page changed. The calculation uses no network service, clock, randomness, locale rules, or mutable state, so identical input produces identical JSON every time.

Use the result in a PDF processing workflow

A downstream PDF engine can then use the returned ordered list as the requested target mode while logging pages_changed for reporting, validation, or operational metrics. This capability does not open, rasterize, recolor, or return a binary PDF; it transforms the per-page mode description supplied by the caller. That boundary makes it suitable for browser use and deterministic API automation, but callers that need altered pixels must still pass the plan to an appropriate PDF renderer. Automated use costs $0.002 per request, with no additional per-page charge declared for this capability.

What does pages_changed count?

It counts each valid page entry whose trimmed, case-insensitive value was not already grayscale.

What happens when every page is already grayscale?

The request succeeds, every returned page remains grayscale, and pages_changed is zero.

Can I submit an empty pages array?

No. A PDF description must contain at least one page mode, so an empty or missing input returns an invalid_input error.

How much does an automated request cost?

The published price is $0.002 per request, with no additional per-page charge.

Read the full KIT documentation →