Which Font Files Does a Website Need?

For a website, start with WOFF2 files licensed for web embedding. Add another format only when your supported browsers require it. The .ttf and .otf files in the download are often intended for desktop installation, while .eot and SVG font files belong to older compatibility setups.

A minimal web-font declaration is small:

@font-face {
  font-family: "Example Sans";
  src: url("/fonts/example-sans-regular.woff2") format("woff2");
  font-style: normal;
  font-weight: 400;
  font-display: swap;
}

Replace the example filename with an actual web font you may publish. Naming a file in CSS does not convert a desktop font or grant a web licence.

Choose website font files by their job

The useful distinction is between the font data and the container used to deliver it. A file extension does not rank a typeface’s quality.

The WOFF2 specification describes the compression and reconstruction of font data. A compressed web container does not add missing characters or new typographic features to the source font.

OpenType can contain TrueType or PostScript-style outlines. That makes “OTF is better than TTF” an unreliable rule for choosing a web asset. The OpenType and TrueType article covers that distinction separately.

Load the weights the design actually uses

A regular file and a bold file need matching declarations:

@font-face {
  font-family: "Example Sans";
  src: url("/fonts/example-sans-bold.woff2") format("woff2");
  font-style: normal;
  font-weight: 700;
  font-display: swap;
}

body {
  font-family: "Example Sans", system-ui, sans-serif;
}

h1,
strong {
  font-weight: 700;
}

Use that alongside the regular declaration. The @font-face reference documents the source and descriptors used to match files to styles.

An italic file should be declared as italic. Pointing a bold declaration at the regular file gives the browser incorrect information, even if the page still appears to have a usable fallback.

font-display: swap permits fallback text while the font is loading. The fallback font still needs suitable sizing and metrics; a format choice alone does not prevent layout changes.

Add a WOFF fallback deliberately

If your browser requirements include a reason to keep WOFF, list WOFF2 first:

@font-face {
  font-family: "Example Sans";
  src:
    url("/fonts/example-sans-regular.woff2") format("woff2"),
    url("/fonts/example-sans-regular.woff") format("woff");
  font-style: normal;
  font-weight: 400;
  font-display: swap;
}

This replaces the first regular declaration rather than supplementing it with a duplicate face. The browser can choose a supported source from the list.

Keeping every supplied format creates more files to track and more configuration to misunderstand. I would add a fallback to satisfy an actual requirement, not because an old generator included five formats in its output.

Treat variable fonts as another asset choice

A variable font can cover a range of weights in one file. When the supplied font actually supports the range, its declaration might be:

@font-face {
  font-family: "Example Variable";
  src: url("/fonts/example-variable.woff2") format("woff2");
  font-style: normal;
  font-weight: 100 900;
  font-display: swap;
}

The range must match the file’s supported axes. Adding 100 900 to a static font’s CSS does not turn it into a variable font.

The variable fonts guide explains axes and ranges. Compare the actual files your design needs; one variable file is convenient, but the label alone does not prove the smallest download.

Keep old formats out of a new default setup

EOT and SVG fonts can matter when maintaining an old site with a specific browser contract. They are not useful default additions to a new WOFF2-based setup.

SVG fonts are also unrelated to ordinary SVG icons and illustrations. Removing an obsolete .svg font fallback is not a reason to remove the site’s SVG artwork.

TTF and OTF can be valid font sources in some web setups, but shipping the desktop package without checking its licence and size solves the wrong problem. Ask the font vendor for the intended web files first.

Verify the request, the licence, and the characters

Open the actual font URL and inspect the response. A 404 HTML page at a .woff2 path is still a failed font request.

Then check the weight and style used by the element. A correctly loaded file can still be the wrong face for that text.

Finally, inspect the characters your content needs, including Latvian diacritics where applicable. The container does not supply glyphs missing from the font.

I would keep the delivery set small: the formats required by the supported browsers, the weights used by the design, and the characters present in the content. The separate self-hosting guide covers how to organize that set in a site.

← Back to all articles