Every hosted platform lets you add your own font, and every one of them puts the control somewhere different. The font itself is the same file in all four cases — a WOFF2 — and the mistakes are the same too, so it is worth knowing what they are before you start clicking.
Take the WOFF2 button from any font page here. It is the complete font, repacked for the web at roughly 60% the size of the .ttf, and every one of these platforms accepts it. See Inter or browse the archive.
WordPress
Since the block editor arrived, WordPress has a font library built into the site editor: Appearance, then Editor, then Styles, then Typography, then the font manager. Upload the file there and it becomes available to every block. No plugin, no theme file, no FTP.
The thing to check is what your theme is already loading. A great many themes fetch fonts from Google on every page load whether you use them or not, which is both a second font family downloading in the background and, in the EU, a privacy question — see the GDPR post below. Turning that off in the theme settings is usually the same screen.
Shopify
Shopify’s theme editor offers a font picker with its own library, and a custom font goes in through the Settings, Files upload rather than the editor. Upload the WOFF2 there, copy the file URL Shopify gives you, and reference it from an @font-face rule in your theme’s stylesheet.
Some themes expose a custom CSS box in the editor, which is the easiest place to put the rule. If yours does not, it goes in the theme’s CSS file through the code editor, and it is worth duplicating the theme before you touch it.
Webflow
Project settings, Fonts, Custom fonts, upload. Webflow is the most straightforward of the four and the one that asks the most of you at upload time: it wants to know which weight and which style the file is, because it uses that to build the CSS.
This is where variable fonts trip people. Uploading a variable file and tagging it as one weight gives you one weight. Webflow supports variable fonts, but you have to tell it that is what the file is, and then the weight range works as it should.
Squarespace
Squarespace has no font upload in the visual editor. The route is Design, Custom CSS, where there is a file manager: upload the WOFF2, click it to insert its URL into your CSS, and write the @font-face rule around it. Then apply the family with a CSS rule targeting the elements you want.
It is the fiddliest of the four and it does work. On the Business plan and above, which is what Custom CSS requires.
The three mistakes that are the same everywhere
- Declaring one weight for a variable font. A variable file carries the whole range, and the CSS has to say so — a range like 100 900 rather than a single number. Declare 400 and you get 400, and the platform will look broken.
- Uploading a TTF because it was the first download. It works and it is roughly twice the size it needs to be. Use the WOFF2.
- Leaving the old font loading. Adding a font does not remove the one the theme was already fetching. Check the network tab: two families where you meant one is a common and invisible cost.
Is it allowed?
For the fonts here, yes — including on a commercial store. The SIL Open Font License permits self-hosting, bundling and commercial use with no fee and no attribution, and the licence file inside the download is the only thing that has to stay with it. A font bought from a commercial foundry is a different question: desktop licences frequently exclude web use entirely. What the OFL allows has the detail, and the GDPR post covers why hosting it yourself is now the faster option as well as the private one.
Uploading is half of it — the theme has to be told
Every platform above separates two steps that feel like one: putting the file somewhere it can be served, and telling the theme to use it. Skipping the second is the single most common reason a font "does not work" after an upload that reported success.
- On a theme with a typography panel, choose the uploaded family for each role — headings, body, buttons — rather than for one of them.
- On a theme without one, add a rule to the custom CSS that sets the family on the elements you want, and check that a more specific theme rule is not overriding it.
- If the platform exposes design tokens or CSS variables, set the variable rather than the element. That is the one change that reaches everything consistently.
Why the change did not appear
Hosted platforms cache aggressively, and so do browsers. A font that looks unchanged after an upload is usually a cached stylesheet rather than a failed upload. In order of likelihood: purge the platform’s own cache, then reload with the cache disabled in the developer tools, then check on a device that has never seen the site.
If the file itself changed but the name did not, add a version to the address — many platforms do this automatically, and it is why a CDN can cache a font for a year without ever serving a stale one. The performance side of the same decision is in what your fonts cost your page speed.
Check it on a phone before you announce it
- Open the site on a phone that has never loaded it, on mobile data rather than your own network.
- Look at a heading, a paragraph and a button: those three use the three font roles most themes expose separately.
- Watch the first paint. If the text appears in one face and swaps to another, set font-display so the swap is deliberate rather than accidental.
- Check one page that is not the home page. Themes frequently style the blog or the shop differently from everything else.