Failed to decode downloaded font

Question

This is an error I am getting in Chrome and unfortunately searching for it hasn't given me much results. The font itself is appearing correctly. However I still get this error/warning. More specifically, this is the full warning:

"Failed to decode downloaded font: http://localhost:8000/app/fonts/Lato/"

My CSS are these:

@font-face {
    font-family:"Lato";
    src: url("../fonts/Lato/");
}

html, body {
    font-family:'Lato';
}

I just do not understand. The font is applied correctly, but the warning is always there. Trying to use Sans-Serif makes the font revert to the normal browser font, so that may be it, but I am not sure, and even after searching I have found nothing. Thanks!

EDIT

There are various font files, all from the same family. I am trying to load them all. The font files are .ttf. I am loading them from a local folder, and there are various font-files, like Lato-Black.ttf, Lato-Bold.ttf, Lato-Italic.ttf etc.

Answer 1

In the css rule you have to add the extension of the file. This example with the deepest support possible:

@font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff2') format('woff2'), /* Super Modern Browsers */
       url('webfont.woff') format('woff'), /* Pretty Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
}

EDIT:

"Failed to decode downloaded font" means the font is corrupt, or is incomplete (missing metrics, necessary tables, naming records, a million possible things).

Sometimes this problem is caused by the font itself. Google font provides the correct font you need but if font face is necessary i use Transfonter to generate all font format.

Sometimes is the FTP client that corrupt the file (not in this case because is on local pc). Be sure to transfer file in binary and not in ASCII.

Answer 2

I experienced a similar issue in Visual Studio, which was being caused by an incorrect url() path to the font in question.

I stopped getting this error after changing (for instance):

@@font-face{
    font-family: "Example Font";
    src: url("/Fonts/ExampleFont.eot?#iefix");

to this:

@@font-face{
    font-family: "Example Font";
    src: url("../fonts/ExampleFont.eot?#iefix");

Answer 3

I had to add type="text/css" to my link-tag. I changed it from:

<link href="https://fonts.googleapis.com/css?family=Roboto+Condensed:300,400,700" rel="stylesheet">

to:

<link href="https://fonts.googleapis.com/css?family=Roboto+Condensed:300,400,700" rel="stylesheet" type="text/css">

After I changed it the error disappeared.

Answer 4

Make sure your server is sending the font files with the right mime/type.

I recently have the same problem using nginx because some font mime types are missing from its vanilla /etc/nginx/mime.types file.

I fixed the issue adding the missing mime types in the location where I needed them like this:

location /app/fonts/ {

  #Fonts dir
  alias /var/www/app/fonts/;

  #Include vanilla types
  include mime.types;

  #Missing mime types
  types  {font/truetype ttf;}
  types  {application/font-woff woff;}
  types  {application/font-woff2 woff2;}
}

You can also check this out for extending the mime.types in nginx: extending default nginx mime.types file

Answer 5

I just had the same issue and solved it by changing

src: url("Roboto-Medium-webfont.eot?#iefix")

to

src: url("Roboto-Medium-webfont.eot?#iefix") format('embedded-opentype')

Answer 6

Changing format('woff') to format('font-woff') solves the problem.

Just a little change compared to Germano Plebani's answer

 @font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff2') format('woff2'), /* Super Modern Browsers */
       url('webfont.woff') format('font-woff'), /* Pretty Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
}

Please check if your browser sources can open it and what is the type

Answer 7

For me, this error was occuring when I referenced a google font using https. When I switched to http, the error went away. (and yes, I tried it multiple times to confirm that was the cause)

So I changed:

@import url(https://fonts.googleapis.com/css?family=Roboto:300,400,100,500,900);

To:

@import url(http://fonts.googleapis.com/css?family=Roboto:300,400,100,500,900);

Answer 8

My problem was occurring in browsers different than chrome. Pay attention to the coma between URL and format, this is how everything went back to normal for all the browsers. Honestly, it works without this "format" too but I decided to leave it be.

@font-face {
  font-family: "Roboto";
  src: url("~path_to_font/roboto.ttf"), format("truetype");
}

Answer 9

Sometimes this problem happens when you upload/download the fonts using the wrong FTP method. Fonts must be FTP-ed using binary method, not ASCII. (Depending on your mood, it may feel counterintuitive, lol). If you ftp the font files using ASCII method, you can get this error message. If you ftp your files with an 'auto' method, and you get this error message, try ftp forcing the binary method.

Answer 10

I was having the same issue with font awesome v4.4 and I fixed it by removing the woff2 format. I was getting a warning in Chrome only.

@font-face {
  font-family: 'FontAwesome';
  src: url('../fonts/fontawesome-webfont.eot?v=4.4.0');
  src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.4.0') format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff?v=4.4.0') format('woff'), url('../fonts/fontawesome-webfont.ttf?v=4.4.0') format('truetype'), url('../fonts/fontawesome-webfont.svg?v=4.4.0#fontawesomeregular') format('svg');
  font-weight: normal;
  font-style: normal;
}

Answer 11

In my case it was caused with an incorrect path file, in .htaccess. please check correctness of your file path.

Answer 12

AWS Amplify specific Failed to decode downloaded font issue as above - but adding woff2 to the default Target address /index.html rule in App setting / Rewrites and redirects resolved any woff2 errors

Before

</^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>

After

</^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|woff2|ttf|map|json)$)([^.]+$)/>

Answer 13

For me, the mistake was forgetting to put FTP into binary mode before uploading the font files.

Edit

You can test for this by uploading other types of binary data like images. If they also fail to display, then this may be your issue.

Answer 14

I also had same problem but i have solved by adding 'Content-Type' : 'application/x-font-ttf' in response header for all .ttf files

Answer 15

In my case, this was caused by creating a SVN patch file that encompassed the addition of the font files. Like so:

1. Add font files from local file system to subversioned trunk
2. Trunk works as expected
3. Create SVN patch of trunk changes, to include addition of font files
4. Apply patch to another branch
5. Font files are added to subversioned branch (and can be committed), but are corrupted, yielding error in OP.

The solution was to upload the font files directly into the branch from my local file system. I assume this happened because SVN patch files must convert everything to ASCII format, and don't necessarily retain binary for font files. But that's only a guess.

Answer 16

In my case when downloading a template the font files were just empty files. Probably an issue with the download. Chrome gave this generic error about it. I thought at first the solution of changing from woff to font-woff solved it, but it only made Chrome ignore the fonts. My solution was finding the fonts one by one and downloading/replacing them.

Answer 17

In my case -- using React with Gatsby -- the issue was solved with double-checking all of my paths. I was using React/Gatsby with Sass and the Gatsby source files were looking for the fonts in a different place than the compiled files. Once I duplicated the files into each path this problem was gone.

Answer 18

If you are using express you need to allow serving of static content by adding something like: var server = express(); server.use(express.static('./public')); // where public is the app root folder, with the fonts contained therein, at any level, i.e. public/fonts or public/dist/fonts... // If you are using connect, google for a similar configuration.

Answer 19

I use .Net Framework 4.5/IIS 7

To fix it I put file Web.config in folder with font file.

Content of Web.config:

<?xml version="1.0"?>
<configuration>
  <system.web>
    <authorization>
      <allow users="*" />
    </authorization>
  </system.web>
</configuration>

Answer 20

If it is on the server (not in localhost), then try to upload the fonts manually, because sometimes the FTP client (for example, FileZilla) corrupts the files and it can cause the problem. For me, I uploaded manually using Cpanel interface.

Answer 21

My case looked similar but the font was corrupted (and so impossible to decode). It was caused by configuration in maven. Adding nonFilteredFileExtension for font extensions within maven-resources-plugin helped me:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <configuration>
        <nonFilteredFileExtensions>
            <nonFilteredFileExtension>ttf</nonFilteredFileExtension>
            <nonFilteredFileExtension>otf</nonFilteredFileExtension>
            <nonFilteredFileExtension>woff</nonFilteredFileExtension>
            <nonFilteredFileExtension>woff2</nonFilteredFileExtension>
            <nonFilteredFileExtension>eot</nonFilteredFileExtension>
        </nonFilteredFileExtensions>
    </configuration>
</plugin>

Answer 22

Google also fails...

Yesterday the same issue was caused by something on Google's side, but only on Win7 and some Win10 computers.

https://github.com/google/material-design-icons/issues/1220

Anyway, it was promptly resolved in less than 24 hours.

I suggest always to backup things we depend on from CDN's, like these fonts.

Answer 23

for me it was a problem with lfs files that were not downloaded

git lfs fetch --all

fixed the problem.

see https://github.com/git-lfs/git-lfs/issues/325