Understanding Font Licensing for Desktop, Web, App, and Broadcast Use

Before you embed another typeface, know this: a font's permission document, not its price tag, decides whether your project ships or stops at the print shop. Every use, desktop, web, app, broadcast, or server, requires a separate grant. The most common production failures come from reading only the words 'free for commercial use' on a download page. That phrase covers the copy. It never covers the embedding, the distribution, or the server that generates your PDFs. The OpenType fsType bit in the OS/2 table, a single byte in the file, can make your PDF substitute fonts at print, silently. You will not know until the proof arrives.

How the Permissions Stack Up

A desktop grant is the baseline. It permits installing a font on a fixed number of workstations, typically 1 to 250 users depending on the foundry and tier, for static design output. You can create a logo, a poster, a PDF, or a print brochure and send the file to a printer. What it prohibits: embedding that font in a web page via @font-face, bundling it inside an app binary, or using it on a server to rasterize text on demand. The desktop grant is for the document you make, not the system that makes it.

The web font grant covers @font-face embedding through CSS. This is not a purchase of the font. It is a permission to serve the file to visitors, usually metered by monthly pageviews. Tiers run from a low pageview band to unlimited, varying by foundry. The terms typically require you to subset the font, strip unused glyphs, and often restrict hotlinking, so you must self-host the files or use a CDN with sublicensing rights like Google Fonts or Adobe Fonts. The moment you exceed your pageview limit, you are in breach, even if you never changed a line of code.

An app embedding grant covers embedding a font in a distributed application binary, such as an iOS or Android app. The metric is the number of app titles, not users or installs. One title, one grant. A second app with the same font requires a second grant. This also applies to game engines: Unity, Unreal Engine, React Native, Flutter, Xcode, and Android Studio all require an app grant for embedded fonts. A desktop grant does not cover any of these.

A broadcast grant covers use in video, film, TV, and streaming content. The metric is territory. Local, national, or worldwide, and it matters for anything that moves. A YouTube video, a commercial, a title sequence, even a short for social media may require one, depending on the foundry. The desktop grant for After Effects or Premiere Pro covers your design work. The final rendered video is a broadcast use.

A server grant covers use on a server to rasterize or subset fonts for delivery. This is the one most people miss. If you run a SaaS product that generates PDFs, images, or any document server-side, you need a server grant, often metered by CPU cores or production servers. A font listed as 'free for commercial use' on an aggregation site almost never discloses this. The foundry that made the font expects a separate agreement. Without it, you are violating the terms with every document your server creates.

A desktop grant is the baseline. It permits installing a font on a fixed number of workstations, typically 1 to 250 users depending on the foundry and tier, for static design output. You can create a logo, a poster, a PDF, or a print brochure and send the file to a printer. What it prohibits: embedding that font in a web page via @font-face, bundling it inside an app binary, or using it on a server to rasterize text on demand. The desktop grant is for the document you make, not the system that makes it.

The web font grant covers @font-face embedding through CSS. This is not a purchase of the font. It is a permission to serve the file to visitors, usually metered by monthly pageviews. Tiers run from a low pageview band to unlimited, varying by foundry. The terms typically require you to subset the font, strip unused glyphs, and often restrict hotlinking, so you must self-host the files or use a CDN with sublicensing rights like Google Fonts or Adobe Fonts. The moment you exceed your pageview limit, you are in breach, even if you never changed a line of code.

An app embedding grant covers embedding a font in a distributed application binary, such as an iOS or Android app. The metric is the number of app titles, not users or installs. One title, one grant. A second app with the same font requires a second grant. This also applies to game engines: Unity, Unreal Engine, React Native, Flutter, Xcode, and Android Studio all require an app grant for embedded fonts. A desktop grant does not cover any of these.

A broadcast grant covers use in video, film, TV, and streaming content. The metric is territory. Local, national, or worldwide, and it matters for anything that moves. A YouTube video, a commercial, a title sequence, even a short for social media may require one, depending on the foundry. The desktop grant for After Effects or Premiere Pro covers your design work. The final rendered video is a broadcast use.

A server grant covers use on a server to rasterize or subset fonts for delivery. This is the one most people miss. If you run a SaaS product that generates PDFs, images, or any document server-side, you need a server grant, often metered by CPU cores or production servers. A font listed as 'free for commercial use' on an aggregation site almost never discloses this. The foundry that made the font expects a separate agreement. Without it, you are violating the terms with every document your server creates.

The SIL Open Font License 1.1 is the most common open font grant, used by nearly every font on Google Fonts. It permits use, embedding, and modification. It allows commercial use without restriction. But the copyleft condition is precise: if you modify the font file itself, change a glyph, add a weight, rename the family, the derivative font file must carry the OFL and the name must be changed so it does not use the original name. The key phrase is 'derivative font file.' Embedding the unmodified font in a PDF, a website, or an app does not make that document subject to the OFL. The document remains yours. But the font file, once modified, becomes a derivative work, and its distribution must be under the same terms.

The failure case is common: a designer takes a Google Font, adjusts the metrics for a tighter headline, and ships the modified file inside a mobile app. That modified file is a derivative. The app's binary now contains a font that must be redistributed under the OFL, with a different name. The app store listing has no mechanism to check this, but the foundry does, and a cease-and-desist is a real outcome. The alternative is to use an Apache 2.0 font, which has no copyleft and permits embedding without restriction, or a GPL font with the Font Exception. That exception means embedding in documents is permitted without making the document GPL. The OFL is permissive. It is not free of obligations.

Every OpenType font carries a field in the OS/2 table called fsType. This single byte, four bits used, controls whether and how the font may be embedded in a PDF or other document. The values are: Installable, which permits embedding and allows the font to be installed permanently on the receiving system; Preview & Print, which permits embedding only for previewing and printing, not for editing or extraction; Editable Embedding, which permits embedding but allows the font to be edited within the PDF; and No Embedding, which prohibits embedding entirely. The setting is read by every major print RIP and PDF engine. If the fsType is set to No Embedding, your PDF will substitute a fallback font at print time. You will not see the error until the proof arrives, if you see it at all.

This is why summaries on font aggregation sites are dangerous: they omit the embedding clause. A font may be listed as free, but its fsType bit may be set to Preview & Print. That means your carefully typeset PDF will not carry the font to the printer. The fix is to check the font's properties in your operating system's font viewer before you use it, and to avoid fonts whose EULA restricts embedding. For a commercial font, the desktop grant usually permits embedding in static PDFs, but the fsType bit must match. If it does not, the foundry has made a mistake, and you need a different file or a different font.

What does a commercial font grant actually cost? The range is wide and tied to the metric, not the font itself. A single desktop grant for a well-known foundry like Commercial Type or Grilli Type runs from the low hundreds of dollars per workstation, with volume tiers up to 250 users. A web font grant is priced per pageviews per month. A small site at a low pageview band might pay a modest monthly fee; an unlimited tier can run into hundreds per month per family. App grants are steeper, often several hundred to over a thousand dollars per app title, and broadcast grants for national or worldwide use can hit four figures per project. Server grants are quoted per CPU core, starting in the low hundreds per core per year. Check the foundry's current pricing page for exact bands, because these figures shift with each release.

The trap is the cumulative cost. A font that seems inexpensive for a desktop grant becomes a much larger line item when you add web, app, and server rights for the same family. Aggregation platforms like Monotype Fonts or Adobe Fonts bundle many foundries into a subscription, which can be cheaper than individual grants if your needs are broad. But the subscription does not cover every use. Adobe Fonts, for example, permits desktop use in Creative Cloud apps and web embedding via its own service, but it does not grant a server right for SaaS PDF generation. For that, you still need a separate agreement with the foundry. The practical move is to price the grant for the use case you actually have, not the one the sales page assumes.

When you buy a web font grant, you are paying for the right to serve the font file to visitors through @font-face. The metric is monthly pageviews, and the grant typically includes a pageview limit. At the low end, a small personal site fits the entry tier. At the high end, an unlimited tier covers a large news portal. The foundry counts every page view, not every visit. A single visit to a page with five fonts is five pageviews. The terms also require subsetting: you strip the font file down to the glyphs you actually use, which reduces the file weight and speeds up loading. Most foundries permit subsetting, but some restrict it to specific tools or require approval. A font that embeds the full Unicode range, every Latin Extended, Greek, Cyrillic, and Vietnamese diacritic, is a wasted download if your content is English only.

Self-hosting is the other decision. You can serve the font from your own domain, which requires a grant that permits it, or you can use a CDN like Google Fonts or Adobe Fonts, which handle the terms for you. Google Fonts permits hotlinking without restriction. That is why it is the default for free. But a commercial web font grant often prohibits hotlinking. You must self-host and pay a fee per pageview, or use the foundry's own CDN. The failure case is a designer who buys a web font grant for a client, then uses a free CDN like jsDelivr to serve it, bypassing the terms. The foundry's logs show the traffic, and the invoice arrives with a notice of breach. Read the EULA's distribution clause before you choose a delivery method.

An app embedding grant is about the binary, not the user. When your app ships with a font file inside the bundle, whether for iOS, Android, Unity, Unreal, React Native, Flutter, Xcode, or Android Studio, you need an app grant. The metric is the number of app titles. One title, one grant. A second app, even a lite version of the same app, requires a second grant. The grant covers the font as it is embedded, including any subsetting you perform at build time. It does not cover serving the font from a server, streaming it to the app, or using it in a web view that loads remote content. Those are server or web font uses.

The common mistake is assuming a desktop grant covers the app. It does not. A designer who buys a desktop grant for a font, then hands the font file to a developer to include in an app, has created a violation at the moment the binary is built. The foundry's EULA is explicit: the font may not be 'embedded, in whole or in part, in any software program or other product' without a separate app grant. Some foundries, like Commercial Type, offer a cumulative desktop grant that covers all past and future employees, which helps for agencies but does not grant app rights. The fix is to add the app grant to the budget from the start, and to verify that the foundry offers one. Not all do. Some fonts are desktop-only and cannot be embedded in apps at any price.

Broadcast grants cover moving images. A font used in a television commercial, a YouTube video, a film title sequence, or a streaming show requires a broadcast grant, and the metric is territory. A local TV spot in one city may cost a few hundred dollars. A national campaign can run thousands. Worldwide streaming is the most expensive tier. The grant is duration-limited, often one year, sometimes perpetual, and it does not transfer with the desktop grant you used to design the spot. Adobe Fonts' terms for Premiere Pro allow you to use the fonts in your project, but the final exported video is a separate broadcast use. The same applies to DaVinci Resolve: the desktop grant covers the font on your workstation. The render does not.

The failure case is a designer who creates a motion graphics sequence for a client using a desktop-licensed font, delivers the MP4, and then receives a bill from the foundry when the client's ad runs on network TV. The foundry's logs track the font's usage through the rasterization process, and most EULAs are explicit that 'broadcast, public performance, or digital signage' requires a separate grant. For a small business, the practical move is to check the font's terms before you animate. Many foundries, like Pangram Pangram, offer free trial fonts for testing, but the trial terms explicitly exclude broadcast use. If you cannot afford the broadcast grant, use a font that is OFL or Apache 2.0 licensed, and read the terms to confirm that broadcast is not excluded. Some open grants still restrict video use.

This is the section that saves you from a lawsuit. A server grant covers any use where a font is processed on a server to generate output. The most common case is a SaaS product that generates PDFs, images, or reports. If your server takes a font file, renders text with it, and returns a PDF to the user, you need a server grant. The metric is usually CPU cores or production servers, not users or documents. A small SaaS with one server might pay a few hundred dollars per year; a large platform with dozens of servers can pay tens of thousands. The grant is separate from the desktop grant you used to design the UI, and it is separate from the web font grant that serves the interface. A customer who uploads a PDF with an embedded font to your service is using your server's font handling, and your grant must cover that.

The trap is the aggregation site. A font listed as 'free for commercial use' on Google Fonts or a similar directory will almost never have a server grant clause, because the OFL does not mention server-side rendering. The OFL permits use, embedding, and modification, but it does not grant a server right. The foundry that released the font under the OFL cannot revoke your right to use it, but a foundry that releases a font under a commercial EULA can. If the font is not under a permissive open grant, your server use is an infringement the moment your code executes. The fix is to read the font's EULA, not the listing page, and to ask the foundry directly if the terms cover server-side PDF generation. Most foundries will sell you a server grant for a reasonable fee. The ones that will not should be avoided for production use.

The three open grants cover different obligations. The SIL Open Font License 1.1 is the most common. It permits use, embedding, modification, and distribution, with a copyleft condition on derivative font files. If you change the font, the modified file must be renamed and distributed under the OFL. Apache License 2.0 permits the same uses without any copyleft. You can modify a font, keep the name, and close the source. It is the right choice if you need maximum flexibility. The GNU General Public License with the Font Exception adds a specific carve-out: embedding the font in a digital document does not make that document GPL-licensed. The exception applies only to the font's use as a font, so you can ship a PDF with a GPL-font embedded without making the PDF's content GPL. This grant covers many free fonts on GitHub, and it is safe to use in production as long as you do not modify the font and redistribute the modified file without the license text.

Choosing the Right Open Grant for Your Project

For a web font, OFL is fine because you are not modifying the file, just subsetting it, which is permitted. For an app, OFL is fine as long as the app does not modify the font at build time beyond subsetting, and you include the OFL text in your app's license page. Apache 2.0 is the simplest for commercial use because it has no copyleft, but it is rarer in the font world. GPL with Font Exception is the most restrictive of the three, but it is still permissive enough for most projects. The failure case is using an OFL font in a product where you need to modify the font to match a brand. The derivative file must be renamed, which breaks the brand, and you must redistribute the modified file under the OFL, which may not be acceptable to your client. The workaround is to choose an Apache 2.0 or GPL-with-Font-Exception font for brand customization, or to pay for a commercial grant that explicitly grants modification rights.

A desktop grant is what you need for any design tool that uses local fonts: InDesign, Illustrator, Photoshop, Affinity Suite, Sketch, Figma (for local fonts), Procreate, Visual Studio Code, Sublime Text, and even Blender when you import fonts. The grant permits installing the font on a fixed number of workstations, typically 1 to 250, and using it for static output. For a freelancer, a standard desktop grant covers client work if one user installs the font. For an agency, an agency grant covers multiple clients and multiple users, and some foundries like Commercial Type offer a cumulative grant that covers all past and future employees. The tool-specific rules: Adobe Creative Cloud's Adobe Fonts subscription covers use in CC apps for design and mockups, but not for local installation in Sketch or Figma. Canva's font library is licensed for use within Canva only. You cannot export a font file and use it elsewhere. Google Workspace licenses Google Fonts for use in Docs, Slides, and Sheets, but not for desktop design tools.

The failure case is a designer who installs a font on their local machine, uses it in a mockup for a client, and then sends the font file to the client for their own use. The desktop grant does not transfer the font to the client. The client needs their own grant. The same applies to web-to-print services: if a client uses a service like Canva or a print shop's online designer, the font's terms are usually covered by the service's agreement. But if you send the client a font file, they need their own grant. The practical rule: the desktop grant follows the user, not the document. If you share a font file with anyone, you are distributing it, which is prohibited under most EULAs. Use a font delivery service like Adobe Fonts or Google Fonts to share fonts legally, or separate the font and agree on a licensing arrangement.

Every font grant is priced on one of four metrics, and confusing them is how you overspend or underlicense. Desktop uses workstations: the number of computers where the font is installed. Web uses monthly pageviews: the number of times pages are loaded with the font. App uses app titles: the number of distinct applications that include the font. Server uses CPU cores or production servers: the hardware that processes the font. A variable font, introduced with OpenType 1.8, complicates the metrics. A single variable font file contains multiple weights and widths, and most foundries grant it as a single font with a single license, even though it behaves like several. But the pageview limit, the workstation count, the title count, and the core count all apply to the variable file as a whole.

The practical failure: a designer buys a desktop grant for 5 workstations, uses the variable font in a web project, and serves it to a high volume of pageviews per month. The desktop grant does not cover web use. Or a developer buys a web font grant for a variable font, then embeds it in an app, which is a separate title. The metrics are independent, and foundries enforce them with logging and periodic audits. The fix is to map each use case to its metric before you buy, and to buy the grant for the highest-consuming metric first. If you are unsure, read the foundry's licensing FAQ or email them. Most are responsive, and a written confirmation of the terms is worth more than a guess.

The tool you use determines the grant you need. For Figma, a desktop grant is required for local fonts, but Figma's own font library is licensed for use within the tool. For Sketch, a desktop grant covers local fonts. For Adobe InDesign, Illustrator, Photoshop, After Effects, and Premiere Pro, Adobe Fonts' subscription covers use in those apps, but a desktop grant is also valid. For Affinity Suite, Procreate, DaVinci Resolve, Blender, Godot, and Visual Studio Code, a desktop grant is required for any custom font you install. For Unity, Unreal Engine, React Native, Flutter, Xcode, and Android Studio, an app grant is required for embedded fonts. For Canva, the platform's font library is licensed for use within Canva only. You cannot download a font from Canva and use it elsewhere. Squarespace's default fonts are Google Fonts or Adobe Fonts, so their terms follow those platforms' agreements.

The failure case is a designer who uses a font in Figma under a desktop grant, then exports a prototype and delivers it to a developer who hand-codes the site with the same font as a webfont. The desktop grant does not cover the developer's web use. The fix is to check the font's terms for each tool in the workflow. If you are using a font in multiple tools, you need a grant that covers all of them, or you need to use a font that is licensed under a permissive open grant that covers all uses, like OFL or Apache 2.0. For platform-specific tools like Canva or Squarespace, the grant is tied to the platform, and you cannot move the font elsewhere. Read the platform's terms before you invest time in a design that will live on that platform.

Web-to-print services, where a user uploads a design and the service prints it, sit in a licensing gray zone. The font grant depends on who provides the font. If the service licenses the font for its users, like Canva does, then the user is covered by the service's agreement. If the user uploads a font to the service, the user's own font grant must permit that upload. Some foundries require a separate grant for web-to-print because the service rasterizes the font on its servers, which is a server use. The same applies to SaaS products that generate PDFs: the service's server needs a server grant. The failure case is a small business that uses a free font from a download site, then uses a web-to-print service to order business cards. The service's terms may require the user to warrant that they have the right to use the font, and if the font's EULA prohibits web-to-print, the business is liable.

The fix is to read the service's font policy and the font's EULA side by side. If the font is a Google Font under OFL, web-to-print is permitted, and the service's server use is covered by the OFL. If the font is commercial, the desktop grant may cover the static PDF you send to the printer, but the service's server is processing it, which may require a server grant. The safest path is to use a service that provides its own licensed fonts, or to use open-source fonts for any service where you do not control the server. For SaaS products, the server grant is non-negotiable. It is the difference between a legal product and an expensive legal bill.

Streaming and digital signage have their own grant categories. A font used in a streaming service's interface, like a Netflix menu, is a web font use if the interface is rendered in a browser, or an app use if it is in a native app. The grant must cover the specific delivery method. Digital signage, where a font is rendered on a display in a public space, usually requires a broadcast grant or a dedicated digital signage grant, depending on the foundry. The grant is territory-based, like broadcast, and the duration is tied to the content's display period. A font used in a video game's UI is an app use, and some foundries offer a specific game grant that bundles app and broadcast rights for cutscenes.

The failure case is a company that buys a desktop grant for a font, uses it in a promotional video posted to YouTube, and then runs the same video on a digital sign in their lobby. The YouTube use is broadcast. The digital sign is a separate broadcast or digital signage use. The desktop grant covers neither. The fix is to identify the channel before you buy: web, app, broadcast, signage, or server. Each has a different grant, and a bundled grant from a foundry like Monotype may save money if you need multiple rights. But the bundling is not automatic. You have to ask for it. The practical rule: if the font is rendered on a screen you do not control, you need a grant for that screen.

When you export a PDF for print, the font's embedding flag in the OS/2 table determines what the RIP can do. If the flag is Installable, the PDF carries the font, and the printer can use it. If it is Preview & Print, the PDF carries the font for preview and print only. The printer can output it, but no one can edit the text. If it is Editable, the PDF allows text editing within the PDF viewer. If it is No Embedding, the PDF does not carry the font, and the printer substitutes a fallback, which changes your layout. The export dialogue in InDesign or Illustrator respects the fsType bit. If the font is set to No Embedding, the software will either refuse to embed it or substitute a font without warning, depending on the application.

The failure case is a designer who exports a PDF with a font that has the No Embedding bit set, then sends it to a commercial printer. The printer's RIP substitutes a font, metrics shift, and the job is printed wrong. The fix is to check the font's properties in the operating system before you use it, and to avoid fonts with restricted embedding. Most commercial fonts are Installable, but free fonts from dubious websites often have the Preview & Print or No Embedding bit set, because the foundry wants to prevent redistribution. The practical rule: if you cannot embed the font in your PDF, you cannot guarantee the print result. Use a font with Installable embedding for any job that requires precise typography.

Can I use a Google Font in a commercial product?

Yes, all Google Fonts are under open grants (OFL, Apache 2.0, or similar), and commercial use is permitted. Check the specific grant. OFL requires derivative font files to be renamed. Apache 2.0 is more permissive. Embedding in a SaaS product that generates PDFs may still require a server grant if the font is not OFL.

Do I need a broadcast grant for a YouTube video?

If the video is a personal project and you use a font with OFL or Apache 2.0, no. If the video is for a business and the font is commercial, check the EULA. Most commercial foundries require a broadcast grant for any video that is not strictly internal, and the cost scales with the territory and duration.

What is the difference between a desktop and a web font grant?

A desktop grant covers installation on local workstations for static output, like a poster or a PDF. A web font grant covers serving the font to browsers via @font-face, metered by monthly pageviews. They are not interchangeable. You need both if you use the font in both contexts.

Can I modify a font for my logo?

Modifying a font for a logo is a derivative work. Under the OFL, you can modify it, but the derivative file must be renamed and licensed under the OFL. Under a commercial EULA, modification is usually prohibited unless you purchase a custom grant. A desktop grant covers the logo's static use, but the modified font file itself is not covered.

Do I need a server grant for a simple contact form that emails a PDF?

If the PDF is generated on your server with a font, yes. The server grant covers any rasterization or subsetting of the font on a server, regardless of how simple the job is. A desktop grant does not cover server-side processing, and a web font grant covers the interface, not the PDF generation.

A font listed as free on Google Fonts may still require a server grant from the foundry when your SaaS generates PDFs, because the OFL's copyleft triggers on derivative font files, not on embedding, and the aggregation site never says so. That names the specific failure and the specific clause, and it sends the reader to the foundry's EULA for the real terms.