How to Detect Typekit (Adobe Fonts) on Any Website (2026)

Typekit has not officially existed since 2018, and yet it is still one of the most-detected font technologies on the web. That is because when Adobe rebranded the service to Adobe Fonts, the serving infrastructure kept its old hostnames: every site using it today still loads a stylesheet from use.typekit.net, exactly as it did a decade ago. Those hostnames are the detection signature, and they are impossible to hide.

This guide covers how to detect Typekit by hand in under a minute, why the manual approach stops working the moment you have a list of domains instead of one, and how to do the same check programmatically with the DetectZeStack API. Every response shown below comes from the live API against a real site.

What Is Typekit (and Why It's Now Adobe Fonts)

Typekit launched in 2009 as a subscription library of licensed web fonts, was acquired by Adobe in 2011, and was folded into Creative Cloud as Adobe Fonts in 2018. The product name changed; the plumbing did not. Web projects are still identified by a short kit ID, stylesheets are still served from use.typekit.net, and the legacy JavaScript loader still lives on use.typekit.com.

That continuity has a practical consequence for anyone doing technology detection: Typekit and Adobe Fonts are the same signal. Fingerprint databases carry both names because both eras of the product left embeds in the wild, and both fingerprints match the same hostnames. Scan a site with a live embed and you will get two results describing one integration. This is expected, and we will see it in a real API response below.

The signal is also worth detecting. Adobe Fonts rides on a paid Creative Cloud subscription, so unlike a free font CDN, its presence tells you the company behind the site pays for typography. If you want to turn that into a prospect list rather than a yes/no check, see how to find companies using Adobe Fonts, which applies this detection to sales prospecting end to end.

Manual Ways to Detect Typekit on a Website

For a single site you already have open in a browser, three manual checks settle the question.

Check for use.typekit.net Script and Stylesheet URLs

View the page source (Ctrl+U in most browsers) and search for typekit. The modern embed is a stylesheet link in the head:

<link rel="stylesheet" href="https://use.typekit.net/abc1def.css">

Older integrations use the JavaScript embed instead: a script served from use.typekit.com plus a load call:

<script src="https://use.typekit.com/abc1def.js"></script>
<script>try{Typekit.load({ async: true });}catch(e){}</script>

Either one is conclusive. No technology other than Adobe's font service loads assets from those hosts, which is why automated detection assigns this signature full confidence.

Look for the Kit ID and wf-loading Body Classes

The short lowercase token in the embed URL, the abc1def above, is the kit ID. Adobe generates one per web project, and it identifies which licensed fonts the page may load. It is visible to anyone, but it is domain-scoped on Adobe's side, so seeing it does not let a third party reuse the fonts.

Sites using the JavaScript embed give you a second, runtime clue. The loader stamps state classes on the html or body element while fonts load: wf-loading while requests are in flight, then wf-active on success or wf-inactive on failure. Open the browser console and check:

document.documentElement.className
// "wf-typekit-active wf-active ..." on a Typekit JS-embed site

Note the limitation: these classes are added by JavaScript at runtime, so they only exist after the page executes its scripts, and only with the JS embed. The stylesheet embed, which is what Adobe generates for new projects, produces no wf-* classes at all. Treat their absence as meaningless and their presence as supporting evidence.

Inspect Network Requests to p.typekit.net

The third check is the network tab. Open developer tools, reload the page, and filter requests by typekit. A site with a live integration shows the kit CSS from use.typekit.net and then the actual font files from p.typekit.net, Adobe's font-serving host. You can do the same from the console without watching the waterfall:

performance.getEntriesByType('resource')
  .map(function(r) { return r.name; })
  .filter(function(u) { return u.indexOf('typekit') !== -1; });

If that returns URLs, the fonts are not just referenced, they are being served. This distinguishes a live integration from a leftover embed pointing at a deleted kit.

Why Manual Detection Breaks at Scale

All three checks above take under a minute for one site. They stop being viable the moment the question changes from "does this site use Typekit?" to "which of these 500 domains use Typekit?" Manual checking at that scale fails in predictable ways:

• It does not batch. Thirty seconds per site is over four hours of tab-switching for 500 domains, with no machine-readable output at the end.
• It is inconsistent. A human checker misses the JS embed on one site, forgets the network tab on another, and mistakes a dead kit for a live one on a third. A fingerprint engine applies the same rules to every domain.
• It captures nothing else. While you are in the page source looking for one string, the site's CMS, analytics stack, and CDN are sitting in the same HTML unrecorded. An API scan returns all of it in one pass.
• It does not repeat. Technology lists go stale. Rescanning a list monthly by hand is not a workflow anyone sustains; rerunning a script is.

The fix is to move the same signatures into an API call.

Detect Typekit With the DetectZeStack API

DetectZeStack detects Typekit server-side from the HTML a site returns: a link tag pointing at use.typekit.net or use.typekit.com, or a script sourced from use.typekit.com. Both patterns resolve at a confidence of 100, and because they sit in the raw HTML, no headless browser is involved.

Try it first with no API key. The /demo endpoint is free and needs no signup; Behance, Adobe's own portfolio network, is a convenient live example:

curl -s "https://detectzestack.com/demo?url=behance.net" \
  | jq '.technologies[] | select(.name == "Typekit")'

Which returns:

{
  "name": "Typekit",
  "categories": [
    "Font scripts"
  ],
  "confidence": 100,
  "description": "Typekit is an online service which offers a subscription library of fonts.",
  "website": "https://typekit.com",
  "icon": "Typekit.png",
  "source": "http"
}

The source field is http, meaning the detection came from the page HTML. That is the only place Typekit can appear: fonts load from Adobe's domain rather than the customer's, so there is no DNS record or TLS artifact to key on. If a site answers a scan with an error page instead of its real HTML, the embed is invisible and the detection cannot fire, which is why checking meta.status_code matters, covered below.

Single Domain Check With /analyze

The demo endpoint is rate limited and meant for spot checks. For real use, get a free API key from RapidAPI and call /analyze, which returns the full stack:

curl -s "https://detectzestack.p.rapidapi.com/analyze?url=behance.net" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" | jq '.'

{
  "url": "https://www.behance.net/",
  "domain": "www.behance.net",
  "technologies": [
    { "name": "Adobe Fonts",   "categories": ["Font scripts"],          "confidence": 100, "source": "http" },
    { "name": "Typekit",       "categories": ["Font scripts"],          "confidence": 100, "source": "http" },
    { "name": "Vue.js",        "categories": ["JavaScript frameworks"], "confidence": 100, "source": "http" },
    { "name": "Varnish",       "categories": ["Caching"],               "confidence": 100, "source": "http" },
    { "name": "HSTS",          "categories": ["Security"],              "confidence": 100, "source": "http" },
    { "name": "HTTP/3",        "categories": ["Miscellaneous"],         "confidence": 100, "source": "http" },
    { "name": "Let's Encrypt", "categories": ["SSL/TLS certificate authority"], "confidence": 70, "source": "tls" }
  ],
  "categories": {
    "Font scripts": ["Adobe Fonts", "Typekit"],
    "JavaScript frameworks": ["Vue.js"],
    "Caching": ["Varnish"],
    "Security": ["HSTS"],
    "Miscellaneous": ["HTTP/3"],
    "SSL/TLS certificate authority": ["Let's Encrypt"]
  },
  "meta": { "status_code": 200, "tech_count": 7, "scan_depth": "full" },
  "cached": false,
  "response_ms": 4415
}

There is the double entry promised earlier: Typekit and Adobe Fonts, both under Font scripts, both matched by the same use.typekit.net embed. Filter on either name, or on the category, and do not count them as two technologies. The categories object makes the category route a single key lookup: .categories["Font scripts"] answers "does this site use a hosted font service?" without walking the array.

Results are cached for 24 hours by default; a repeat scan of the same domain returns "cached": true with a much lower response_ms. That is worth knowing when benchmarking: the second scan measures the cache, not the scanner.

Scanning Many Domains With POST /analyze/batch

Batch is how you work through a list. It accepts up to 10 URLs per request and scans them concurrently:

curl -s -X POST "https://detectzestack.p.rapidapi.com/analyze/batch" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"urls": ["behance.net", "example.com", "stripe.com"]}' \
  | jq -r '.results[]
      | select(.result.technologies[]?.name == "Typekit")
      | .result.domain'

The response wraps one result per URL with a per-item error field, so one unreachable domain does not fail the batch, and the jq filter prints only the domains where Typekit was found. Each URL counts as one request against your monthly quota; batching saves round trips, not quota. For working through lists in the hundreds or thousands, how to batch scan 1,000 websites covers chunking, retries, and rate pacing.

Typekit vs Google Fonts vs Self-Hosted Fonts: Telling Them Apart

Font loading comes in three flavors, and each leaves a different trail:

Both hosted services land in the Font scripts category (Google's entry is named Google Font API), so a category filter catches either while a name filter isolates the paid signal. Self-hosted fonts, by design, have no third-party host to fingerprint; their absence from a scan is not a detection failure but the actual answer. The same host-based logic powers detection of other asset CDNs; detecting cdnjs is the same pattern applied to JavaScript libraries, and detecting Google Tag Manager applies it to the tag-management layer of the same pages.

Get Your API Key and Start Detecting

The free plan covers 100 requests per month with no credit card, which is enough to confirm the signal on the sites you care about; paid plans start at $9 for 1,000 requests. Every plan returns the same full response: Typekit alongside the CMS, analytics, CDN, and everything else in the stack, in one call.

1. Spot-check a site with /demo, no key required.
2. Get a free key at RapidAPI and move to /analyze.
3. Feed your domain list through /analyze/batch, 10 URLs at a time.

Conclusion

Typekit is one of the easiest technologies on the web to detect because it cannot be consumed without advertising itself: the embed sits in the HTML, the hostnames never changed through a rebrand, and there is no false-positive path, since nothing else loads assets from Adobe's font hosts. Check one site by searching the source for use.typekit.net; check five hundred with an API call that applies the same signature uniformly and hands you the rest of the stack for free. Just remember the two quirks: the API returns both Typekit and Adobe Fonts for one integration, and a non-200 status_code means inconclusive, not absent.