ForHosting KIT · Documents & PDF

Estimate PDF font subsetting savings from glyph usage

This estimator compares the number of distinct characters used in a PDF with the complete glyph inventory of its embedded font.

● BetaFree · in your browser

Run — free How it works & API

Use it from WebAPIEmailTelegramApp soon

It reports the estimated percentage of font data retained, the estimated percentage saved, the number of glyphs removed, and a reduction ratio. The calculation is intentionally transparent: it assumes that glyph storage is distributed evenly across the font. That makes it useful for planning and comparison before a PDF is rebuilt, while avoiding a false claim of byte-level precision that the two counts alone cannot support.

What the estimate tells you

A fully embedded font can contain thousands of glyphs even when a document uses only a small alphabet, a few numerals, and punctuation. Font subsetting keeps the glyphs needed to display the document and omits the remainder. Enter the font's complete glyph count and the number of distinct characters actually present in the PDF. The estimator treats each used character as one retained glyph, then compares that subset count with the full inventory. The returned savings percentage is the estimated share of glyph-related font data that could be removed. The retained percentage shows the complementary share, while the reduction ratio expresses how many times larger the full glyph inventory is than the estimated subset. These values are most useful for quickly ranking documents or fonts. A result showing substantial potential savings signals that subsetting deserves attention; a result close to zero indicates that the document already uses most of the font's available glyph inventory. The estimate concerns the embedded font portion, not the entire PDF file. Images, page content streams, metadata, structure, and other embedded resources remain unchanged.

How the proportional model works

The algorithm divides distinct characters used by the full glyph count to estimate the retained fraction. It subtracts that fraction from one to estimate savings, converts both fractions to percentages, and rounds displayed percentages to two decimal places. It also subtracts the used count from the full count to report how many glyphs are candidates for removal. This is a proportional glyph-footprint model, not a font parser. Real fonts do not assign exactly the same number of bytes to every glyph: a simple space may require little outline data, while an intricate ideograph may require much more. Fonts also contain tables for naming, metrics, layout rules, variation axes, hinting, kerning, and character mapping. Some of those tables are fixed overhead, while others may shrink when a subset is built. Accordingly, the estimate is best interpreted as a consistent planning metric under an equal-average-glyph assumption. Absolute byte savings cannot be derived from glyph counts alone. For that calculation, you would also need the original embedded font size and information about the subsetter, font format, compression, retained layout features, and composite-glyph dependencies.

How to obtain reliable input counts

Use the glyph count reported by the exact font program embedded in or intended for the PDF, rather than a similarly named desktop font. Different releases and regional variants can have different inventories. Count distinct characters across the document after text normalization rules have been decided, because visually identical sequences can use different Unicode code points. Remember that character count is not always glyph count. Ligatures may combine several characters into one glyph, contextual shaping may select different glyph forms, and composite glyphs can pull in components that are not obvious from the text. This estimator deliberately uses the supplied distinct-character count as a practical proxy because that is the information available. For comparative planning, apply the same counting method to every candidate document so the estimates remain consistent. If the used-character count exceeds the full glyph count, the request is rejected rather than producing a negative saving. That condition usually indicates mismatched sources, confusion between total and distinct character counts, or a font fallback that was omitted from the inventory. After generating the real subset PDF, verify the final result with a PDF inspector and compare actual file sizes for the definitive measurement.

What you can do with it

Prioritize PDF optimization work

Compare estimated font savings across a batch and investigate the documents with the largest unused glyph share first.

Evaluate font choices

Estimate whether a broad multilingual font creates significantly more embedding overhead than a font tailored to the document's script.

Set expectations before export

Give production teams a transparent relative estimate before rebuilding a PDF with font subsetting enabled.

FAQ

Does the result predict exact bytes saved?

No. Glyph counts support a relative estimate, but exact bytes also depend on glyph complexity, font tables, format, compression, and subsetter behavior.

Why use distinct characters instead of total characters?

Repeated characters normally reuse the same embedded glyph, so distinct usage is a more relevant proxy for the subset inventory.

Does the savings percentage apply to the whole PDF?

No. It applies to the estimated glyph-related portion of the embedded font. Other PDF content is unaffected.

What happens when used characters exceed the font glyph count?

The input is rejected because the counts are inconsistent and would otherwise imply negative savings.

Can zero distinct characters be entered?

Yes. It represents a theoretical document that retains no character glyphs and produces a complete proportional saving estimate.

What does an API request cost?

Each API request costs $0.002; the same deterministic calculation can also run in the browser.

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

POSThttps://api.kit.forhosting.com/pdf/embed-font-subset-estimate

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/embed-font-subset-estimate \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"full_glyph_count":2048,"distinct_characters_used":180}'

const res = await fetch("https://api.kit.forhosting.com/pdf/embed-font-subset-estimate", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "full_glyph_count": 2048,
    "distinct_characters_used": 180
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/pdf/embed-font-subset-estimate",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "full_glyph_count": 2048,
    "distinct_characters_used": 180
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/pdf/embed-font-subset-estimate", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"full_glyph_count":2048,"distinct_characters_used":180}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"full_glyph_count":2048,"distinct_characters_used":180}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/pdf/embed-font-subset-estimate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "full_glyph_count": 2048,
  "distinct_characters_used": 180
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "pdf.embed_font_subset_estimate",
  "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

Per request$0.002

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.

Read the full KIT documentation →