Webpack OTS parsing error loading fonts

Question

My webpack config specifies that fonts should be loaded using url-loader  and when I try to view the page using Chrome I get the following error   OTS parsing error  invalid version tag Failed to decode downloaded font   My local URL    The relevant parts of my config look like this       module        loaders                                 test     scss            loaders    style    css sourceMap    autoprefixer    sass sourceMap                             test   images       png jpg svg gif             loader   url-loader limit 10000 amp name   name - hash   ext                              test   fonts       woff woff2 eot ttf svg             loader   file-loader name   name - hash   ext                             It doesn t happen in Safari  and I haven t tried Firefox   In development I m serving files through webpack-dev-server  in production they re written to disk and copied to S3  in both cases I get the same behaviour in Chrome   This also happens to larger images  greater than the 10kB limit in the image loader config

User · Answer

I just had the same issue with Font Awesome. Turned out this was caused by a problem with FTP. The file was uploaded as text (ASCII) instead of binary, which corrupted the file. I simply changed my FTP software to binary, re-uploaded the font files, and then it all worked.

https://css-tricks.com/forums/topic/custom-fonts-returns-failed-to-decode-downloaded-font/ this helped me in the end I had the same issue with FTP transferring files as text

User · Answer

In my case adding following lines to lambda js  my deployed is on AWS Lambda  fixed the issue     font opentype     font sfnt     font ttf     font woff     font woff2

User · Answer

For me the problem was my regex expression  The below did the trick to get bootstrap working         test      woff ttf eot svg    v  a-z0-9    a-z0-9    a-z0-9           loader   url-loader limit 100000

User · Answer

I know this doesn t answer OPs exact question but I came here with the same symptom but a different cause    I had the  scss files of Slick Slider included like this    import           node modules slick-carousel slick slick scss     On closer inspection it turned out that the it was trying to load the font from an invalid location   lt host gt  assets css fonts slick woff   the way it was referenced from the stylesheet   I ended up simply copying the  font  to my assets css  and the issue was resolved for me

User · Answer

As asnwered here by  mcortesi if you remove the sourceMaps from the css loader query the css will be built without use of blob and the data urls will be parsed fine

User · Answer

As with  user3006381 above  my issue was not just relative URLs but that webpack was placing the files as if they were javascript files  Their contents were all basically   module exports     webpack public path      7410dd7fd1616d9a61625679285ff5d4 eot     in the fonts directory instead of the real fonts and the font files were in the output folder under hash codes  To fix this  I had to change the test on my url-loader  in my case my image processor  to not load the fonts folder  I still had to set output publicPath in webpack config js as  will-madden notes in his excellent answer

User · Answer

The best and easiest method is to base64 encode the font file  And use it in font-face  For encoding  go to the folder having the font-file and use the command in terminal    base64 Roboto ttf  gt  basecodedtext txt   You will get an output file named basecodedtext txt  Open that file   Remove any white spaces in that   Copy that code and add the following line to the CSS file    font-face     font-family   font-name     src  url data application x-font-woff charset utf-8 base64  lt  lt paste your code here gt  gt   format  woff          Then you can use the font-family   font-name  in your CSS

User · Answer

If you re using Angular you need to check to make sure your    lt base href     gt     tag comes before your style sheet bundle  I switched my code from this     lt script src    bundles style bundle js  gt  lt  script gt    lt base href        gt    to this     lt base href        gt    lt script src    bundles style bundle js  gt  lt  script gt    and the problem was fixed  Thanks to this post for opening my eyes

User · Answer

I experienced the same problem  but for different reasons    After Will Madden s solution didn t help  I tried every alternative fix I could find via the Intertubes - also to no avail  Exploring further  I just happened to open up one of the font files at issue  The original content of the file had somehow been overwritten by Webpack to include some kind of configuration info  likely from previous tinkering with the file-loader  I replaced the corrupted files with the originals  and voil    the errors disappeared  for both Chrome and Firefox

User · Answer

As of 2018    use MiniCssExtractPlugin  for Webpack   4 0  will solve this problem    https   github com webpack-contrib mini-css-extract-plugin  Using extract-text-webpack-plugin in the accepted answer is NOT recommended for Webpack 4 0

User · Answer

Since you use url-loader      The url-loader works like the file-loader  but can return a DataURL if the file is smaller than a byte limit    So another solution to this problem would be making the limit higher enough that the font files are included as DataURL  for example to 100000 which are more or less 100Kb       module        loaders                                 test     scss            loaders    style    css sourceMap    autoprefixer    sass sourceMap                             test   images       png jpg svg gif             loader   url-loader limit 10000 amp name   name - hash   ext                              test     woff   v  d    d    d               use   url-loader limit 100000 amp mimetype application font-woff                            test     woff2   v  d    d    d               use   url-loader limit 100000 amp mimetype application font-woff                            test     ttf   v  d    d    d               use   url-loader limit 100000 amp mimetype application octet-stream                            test     eot   v  d    d    d               use   file-loader                            test     svg   v  d    d    d               use   url-loader limit 100000 amp mimetype image svg xml                            Allways taking into account on what the limit number represents      Byte limit to inline files as Data URL   This way you don t need to specify the whole URL of the assets  Which can be difficult when you want Webpack to not only respond from localhost   Just one last consideration  this configuration is NOT RECOMMENDED for production  This is just for development easiness

User · Answer

The limit was the clue for my code  but I had to specify it like this   use            loader   url-loader       options          limit  8192

User · Answer

TL DR Use absolute paths to your assets  including your complete hostname  by setting your output publicPath to e g   http   example com assets     The problem  The problem is the way that URLs are resolved by Chrome when they re parsed from a dynamically loaded CSS blob   When you load the page  the browser loads your Webpack bundle entry JavaScript file  which  when you re using the style-loader  also contains a Base64 encoded copy of your CSS  which gets loaded into the page         This is what it looks like in Chrome DevTools   That s fine for all the images or fonts which are encoded into the CSS as data URIs  i e  the content of the file is embedded in the CSS   but for assets referenced by URL  the browser has to find and fetch the file   Now by default the file-loader  which url-loader delegates to for large files  will use relative URLs to reference assets - and that s the problem         These are the URLs generated by file-loader by default - relative URLs   When you use relative URLs  Chrome will resolve them relative to the containing CSS file  Ordinarily that s fine  but in this case the containing file is at blob       and any relative URLs are referenced the same way  The end result is that Chrome attempts to load them from the parent HTML file  and ends up trying to parse the HTML file as the content of the font  which obviously won t work   The Solution  Force the file-loader to use absolute paths including the protocol   http  or  https     Change your webpack config to include something equivalent to       output        publicPath   http   localhost 8080       Development Server        publicPath   http   example com       Production Server         Now the URLs that it generates will look like this         Absolute URLs    These URLs will be correctly parsed by Chrome and every other browser   Using extract-text-webpack-plugin  It s worth noting that if you re extracting your CSS to a separate file  you won t have this problem because your CSS will be in a proper file and URLs will be correctly resolved

[css] Webpack "OTS parsing error" loading fonts

Examples related to css

Examples related to fonts

Examples related to webpack

Examples related to webpack-style-loader