Is coolLabs Fonts GDPR friendly, and what data does it log?

coolLabs Fonts is designed as a privacy-friendly, drop-in replacement for Google Fonts: it serves the same fonts through the same CSS API, but the API does not log IP addresses, browser agents, or request details, and font files are delivered via BunnyCDN with logging disabled on their side. That makes it a reasonable option for GDPR-conscious sites that want to stop sending visitor data to Google's servers — though it is a technical privacy measure, not a legal guarantee, and you should still confirm it fits your own compliance obligations.

What coolLabs Fonts actually changes

The core mechanism is a domain swap. Instead of requesting stylesheets from fonts.googleapis.com, your pages request them from api.fonts.coollabs.io. The service states it supports the css2 and css API endpoints of Google Fonts, so existing font declarations keep working after the change. Material Icons are supported too, using the same domain swap for the icon endpoint.

Because the font requests no longer go to Google, visitors' details stay away from Google's servers. The project positions this as a GDPR-friendly setup: font loading is a routine part of nearly every page view, so routing it through a third party that logs requests is exactly the kind of data flow privacy-conscious sites try to avoid.

What data is and isn't logged

The project also describes itself as open source: the API is a small open-source HTTP server, self-hosted with Coolify on a Hetzner server. That matters for verification — you can inspect the server code rather than taking the logging claims on faith.

How to switch your site over

1. Find your font links. Look in your HTML <head> for <link> tags pointing at fonts.googleapis.com, including any css2 stylesheet URLs and Material Icons links.
2. Change the domain. Replace fonts.googleapis.com with api.fonts.coollabs.io in each of those tags. The project's instruction is literally: "In your tags, change fonts.googleapis.com to api.fonts.coollabs.io. That's all!"
3. Verify the result. Load a page and check in your browser's network panel that font CSS and font files now come from api.fonts.coollabs.io (and the CDN), with no remaining requests to fonts.googleapis.com. Confirm the fonts render as before.
4. Check icons separately. If you use Material Icons, apply the same domain swap to the icon endpoint and confirm the icons still display.

Common snags: font URLs hard-coded in a CMS theme, a plugin, or a CSS @import rather than a <link> tag will be missed by a simple search-and-replace; and any locally cached or preloaded references need updating too.

Limits worth knowing before you decide

• It's a privacy measure, not a compliance certificate. The no-logging design and the removal of Google from the request path reduce the data flow, but whether your site meets GDPR depends on your full setup — consent handling, other third parties, and your own records. Treat the service's claims as inputs to that assessment, not a substitute for it.
• You're trusting a smaller operator. coolLabs Fonts is run by a small open-source project funded by sponsors ("Free, because of our sponsors"), not a large provider. The open-source server code and the stated CDN logging configuration are the things to check if that trust matters to you.
• Self-hosting is the stronger option. If you want the most control, hosting font files yourself removes the third-party request entirely; coolLabs Fonts is the lower-effort middle ground when you want Google Fonts compatibility without Google.

If your goal is simply to stop font requests from reaching Google while keeping the same fonts and API, the one-domain swap is a quick, low-risk change. If your goal is a documented GDPR position, use it as one component and verify the logging behavior against the project's source and CDN configuration.