A web font can send a visitor’s IP address to an external service while adding unnecessary weight to every page view. Deciding on hosting, file formats, and fallback fonts early reduces privacy risks, load times, and rework.
A font being free does not mean it comes at no cost to the website. The common search term Google Fonts GDPR compliance captures only part of the problem: the same font choice can create external data flows, unnecessary loading, and expensive design work when text suddenly wraps differently than it does in Figma.
A Google-hosted font normally means that the visitor’s browser retrieves CSS and font files from Google’s servers. A consent banner does not help if the request has already been sent before the visitor’s choice has been processed. At the same time, a web font that loads late can change the width of headings, buttons, and menus, making a seemingly finished design unstable.
This is how we would approach the issue: choose the delivery model before finalising the typography, reduce the font package, and test every important component with both the web font and the fallback font. The decision then becomes a verifiable acceptance criterion rather than a technical surprise shortly before launch.
Google Fonts GDPR compliance: external loading, local hosting, or system fonts?
The straightforward answer is that no single option suits every website. External loading is easy to implement, local hosting provides greater control, and system fonts eliminate font downloads entirely. The right choice depends on how closely the brand is tied to its typography, how much variation the layout can accommodate, and who will maintain the solution.
With external loading, the browser normally contacts a third party to retrieve stylesheets and files. This creates a technical dependency and may result in request data being transferred outside your own environment. The advantage is simple distribution, but that rarely carries much weight if the same visual result can be achieved without the external request.
To host Google Fonts locally means serving the WOFF2 files from your own domain or a controlled delivery environment. You gain greater control over network traffic, but you also assume responsibility for licence terms, file versions, cache management, and the weights being used. Local hosting is therefore an ongoing maintenance model, not merely a matter of moving files.
System fonts such as system-ui, Segoe UI, and the platforms’ built-in sans-serif fonts require no font download. The page becomes more robust, but its appearance varies between Windows, macOS, Android, and iOS. This can be a sensible choice for content-heavy business websites where readability and straightforward maintenance matter more than identical typography on every device.
| Option | Data flow | Performance | Maintenance |
|---|---|---|---|
| Google-hosted font | The browser contacts external domains | May require additional connections | Third-party dependency remains |
| Locally hosted font | Can remain within a controlled environment | Depends on file selection and loading strategy | You are responsible for files and licence information |
| System font | No font file needs to be downloaded | Very low delivery overhead | Little technical maintenance but greater visual variation |
The legal assessment must always be based on your actual solution and any other third-party services. This is not legal advice. Use the latest guidance from the Swedish Authority for Privacy Protection, IMY, for questions concerning the processing of personal data.
Local hosting is not automatically fast
A WOFF2 file on your own domain can still be a performance liability. If the website loads multiple families, italics, variable axes, and weights that never appear in the interface, the cost has simply been moved from Google to your own server. The files then compete with images, JavaScript, and other content the visitor is actually waiting for.
Start with the design’s actual requirements. If the body text uses the regular style and the headings use two weights, there is rarely any reason to deliver the entire font family. A streamlined declaration might look like this:
@font-face {
font-family: "Profil Sans";
src: url("/fonts/profil-sans-regular.woff2") format("woff2");
font-weight: 400;
font-style: normal;
font-display: swap;
}font-display: swap allows a fallback font to appear while the web font is being downloaded, so the text does not need to remain invisible during the wait. However, the change can shift the layout if the fonts have different metrics. These unexpected shifts affect CLS, the Core Web Vitals metric that, according to Google’s web.dev, measures visual stability.
The CSS descriptors size-adjust, ascent-override, descent-override, and line-gap-override can be used to make the fallback font’s metrics more closely match the brand font. The values should be determined by comparing the specific fonts, not copied from a generic example. The aim is for headings and components to retain roughly the same shape before and after the font change.
Preloading requires the same restraint. Only preload a font that is definitely needed in the initial visible content, and ensure that the URL, format, and crossorigin setting match the declaration in @font-face. Otherwise, the browser may prioritise the wrong file or download the same resource again, undermining the entire optimisation.
The first place we look after a migration is the browser’s Network panel. Filter by fonts and verify that no requests are sent to fonts.googleapis.com, fonts.gstatic.com, or a forgotten provider. At the same time, confirm that every loaded weight is actually used; locally hosted fonts only become efficient when their delivery is intentional.
Define typography tolerances before the design becomes expensive to change
What happens to the navigation when the fallback font is wider than the brand font? A link may wrap, button text may be cut off, and a main heading may take up an extra line. This creates more than a visual defect: it can also require component rebuilds, new design decisions, and additional testing late in the project.
The test material should include the company’s actual menu labels, longest button labels, and Swedish words containing å, ä, and ö. Also test forms, error messages, and headings at narrow screen widths. A simple set of acceptance criteria might look like this:
| Component | Example text | Check with web font | Check with fallback font |
|---|---|---|---|
| Main heading | Change you can feel every day | Line breaks and heading height | No overlapping or truncated text |
| Navigation | Sustainability reporting | Spacing between links | Works without unintended wrapping |
| Button | Book a free consultation | Text and horizontal padding | The text fits within the component |
| Form field | Company email address | Label position | No change to component height |
| Body text | Our services are tailored to small and growing businesses. | Readability and rhythm | Å, ä, and ö display correctly |
The delivery documentation should also specify the font source, licence information, file format, weights used, fallback stack, and the person responsible for future updates. Documentation cannot prevent every mistake, but it reduces the risk of a future agency reintroducing external requests or loading the entire family to recreate the design.
A useful compromise is often a locally hosted brand font for a limited number of headings and a system font for body text and interface elements. The brand retains its character where it is most noticeable, while most of the text remains fast and robust. However, the decision should be based on tested components, not on how an isolated typography sample looks.
The criteria that should determine your font choice
Do not assess fonts solely by their appearance or file location. A sustainable choice limits external requests, keeps performance costs down, and gives the design clear tolerances for different devices and loading states.
Map the external requests created by your font choice
Check whether the browser needs to contact Google or another third party for CSS and font files. Local hosting and system fonts generally provide greater technical control, but the legal assessment must be based on your own solution.
Signal: No unexpected font requests should be sent to external domains in the Network panel.
Reduce the font package to what the interface actually uses
Audit families, weights, styles, and character sets before packaging the files. Subsets can reduce data transfer, but only after Swedish characters, special characters, and the organisation’s other languages have been checked.
Signal: Flag any case where every page loads an entire font library even though the design uses only a few variants.
Control when and how the fonts load
Prioritise only the files needed for the initial visible content. Visitors must be able to read and use the page even when the web font loads slowly or is blocked.
Signal: Every preloaded font should have a clear purpose, and the fallback state should work without major shifts.
Define typography tolerances before the design becomes fixed
Define fallback fonts, permitted line breaks, and component heights before the typography spreads throughout the design system. The brand font must not be the only scenario in which the navigation, forms, and buttons work.
Signal: No text should overlap, be truncated, or make a core function unusable when the fallback font is used.
Choose a solution the team can maintain
Local hosting transfers responsibility for file versions, caching, licence information, and updates to your organisation. External loading instead retains a third-party dependency that must be reviewed whenever the technology or design changes.
Signal: Someone should be able to identify the source of the files, how they are used, and who is responsible for future changes.
Start here: take control of your fonts
-
Map all external font requests
Open Chrome DevTools, select Network, and filter by
Font,fonts.googleapis.com, andfonts.gstatic.com. Check several page types and consider supplementing the review with Webbkoll. In WordPress, requests may come from themes and plugins; in React, they may be found in global stylesheets or component packages. -
Move Google Fonts to your own hosting
Retrieve the correct font files and licence information from the official Google Fonts repository or package them with Fontsource. Serve WOFF2 files from your own domain or a controlled CDN, add local
@font-facerules, and remove old links,@importrules, andpreconnectrequests to Google. -
Limit the number of weights and characters
Keep only the weights and styles that are actually used. For larger font packages, the FontTools command
pyftsubsetor Glyphhanger can create language-based subsets, but always test Swedish characters, symbols, and every publishing language before deployment. -
Make font loading non-blocking
Use
font-display: swap, define a robust fallback stack, and preload only files that are definitely needed immediately. If necessary, adjust the fallback font’s metrics withsize-adjustand related descriptors so that quickly visible text does not come at the cost of a shifting layout. -
Verify and monitor the results
Test representative pages with a cold cache and a simulated slower connection in Lighthouse, PageSpeed Insights, and WebPageTest. Then combine Lighthouse CI or an equivalent tool with an allowlist of permitted domains so that external font requests and degraded web font performance are detected before publication.
The question of Google Fonts GDPR compliance should therefore lead to a concrete delivery requirement: known data flows, a documented font source, a limited set of files, and a tested fallback state. Self-hosting provides greater control but does not in itself guarantee regulatory compliance. This is not legal advice, and the legal assessment should be based on IMY’s guidance at imy.se. An experienced team therefore starts with network traffic and component testing, not with a promise that a particular font solution will always be safe or fast.
