Check PDF linearization and fast web view status
PDF linearization is a structural arrangement designed to let a compatible viewer show the first page while the rest of a remote document is still downloading.
Run — free
This checker takes the Boolean linearization flag produced by a PDF inspection tool and turns it into a concise, report-ready finding. It states whether fast web view is advertised, explains the practical effect, separates delivery optimization from file validity, and suggests the appropriate next step without uploading or rewriting the PDF itself.
Read the structural flag correctly
A PDF inspector may expose linearization as a Boolean flag, sometimes alongside labels such as Fast Web View or Web Optimized. Supply that exact structural result in the linearized field: true means the expected linearization dictionary and ordering were recognized, while false means the file does not advertise that arrangement. The checker deliberately requires the flag instead of guessing from a filename, file size, download speed, or metadata label. Those indirect clues cannot establish how objects are ordered inside the document. The result repeats the normalized Boolean, provides a stable status value for automated workflows, and writes a plain-English summary suitable for a technical report. If the inspection output does not contain the flag, do not substitute false. A missing observation means the status is unknown, whereas false is a definite structural finding. The capability therefore returns an input error when the flag is absent or is not a Boolean, preventing an unsupported conclusion from entering an audit or quality-control record.
Understand what fast web view changes
A linearized PDF places information needed for early display near the beginning of the file and includes hints that help a supporting reader request useful byte ranges. When the file is hosted on a server that honors range requests, a compatible browser or PDF viewer may render the opening page before every byte has arrived. That can improve perceived responsiveness for large documents, slow connections, and readers who only need the first few pages. The report uses careful language because the structural flag is an enabling condition, not a performance guarantee. Actual behavior also depends on HTTP delivery, caching, network latency, viewer implementation, document complexity, and later transformations performed by a content pipeline. Linearization does not compress the PDF, reduce its page count, certify accessibility, validate signatures, or prove that the document is otherwise well formed. Likewise, a non-linearized PDF can still open quickly when it is small or cached. The finding should therefore describe progressive-delivery readiness rather than claim a measured speed improvement.
Use the finding in a report or workflow
For a positive result, record that the PDF is linearized and supports fast web view, then retain the caveat that delivery conditions determine the observed benefit. For a negative result, report that fast web view is not advertised and that remote first-page display may require more of the file to download. Avoid calling the document corrupt: non-linearized PDFs are common and can remain completely valid. The recommendation is conditional—linearize the file when progressive HTTP viewing matters, then inspect the rewritten output again. This matters because editing, optimizing, signing, merging, or regenerating a PDF can change its internal ordering and remove a previously valid linearization structure. In automated publishing, run a PDF structural inspection after the final document-producing step, pass its Boolean flag here, and store the returned status and explanation with the release evidence. The stable fields also make policy checks straightforward: a web-publication workflow can require true, while an archival or local-distribution workflow can accept either value and preserve the result only for information.
What you can do with it
Document a web publishing check
Turn an inspector's structural flag into a consistent finding before a large PDF is released on a website.
Normalize quality-control output
Convert true or false into stable status fields and report language that downstream checks can store and compare.
Explain a negative result safely
Clarify that missing fast web view optimization affects progressive delivery but does not by itself mean the PDF is invalid.
FAQ
What input does the checker need?
It needs the Boolean linearized flag from a PDF structural inspection: true or false. It does not accept an absent or unknown flag as false.
Does this capability inspect or upload the PDF file?
No. It interprets a structural flag that another PDF inspection step has already produced.
Does linearized mean the PDF will always open faster?
No. It enables progressive delivery, but the server, viewer, connection, cache, document complexity, and file size determine the actual experience.
Is a non-linearized PDF broken?
No. Lack of linearization is a delivery-optimization finding, not proof of corruption or invalidity.
Can editing remove linearization?
Yes. Rewriting, merging, signing, or optimizing the file can change object ordering, so inspect the final artifact again.
What does the API request cost?
Each API request costs $0.002. The browser version can run the same deterministic interpretation locally.
For developers — API access
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.
API endpoint
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.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/pdf/linearize-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"linearized":true}'const res = await fetch("https://api.kit.forhosting.com/pdf/linearize-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"linearized": true
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/pdf/linearize-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"linearized": true
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/pdf/linearize-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"linearized":true}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"linearized":true}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/pdf/linearize-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"linearized": true
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "pdf.linearize_check",
"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.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 25 |
max_pages | 200 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |