How to deal with Google Fonts "data breach"?

Recently we've heard from German users they were threatened by law firms because of the Google Fonts used on their sites.

Allegedly those firms collect those sites that use Google Fonts by bots. This way they are able to find even small sites visited by only a handful of people (perhaps relatives only), not posing any risk to their visitors' privacy. At first, I thought these firms were some kind of mafia, masquerading themselves as legal businesses, but they turned out to be real law firms. I believe if they were "bona fide" actors, they had not threatened website owners with a lawsuit right away - perhaps they could have called their attention to the problem first.

In January 2022 a German Court fined a website €100 for leaking their visitor's IP addresses via Google Fonts without their consent. Here's an article on the matter. So far nobody has paid attention to IP addresses, which normally tell a website where to send the requested content back. This is how the internet has worked in the past 30 years. These IP addresses for most home users are dynamic, i.e. they change day by day, and it's only the internet service provider can tell who had that particular IP address at a given time. Those who were afraid their IPs were revealed were already using anonymizers – I believe –, like VPNs or secure browsers (Tor).

Now, this court has decided it's the website that's responsible for hiding the user's IP from a service. Even though the website itself doesn't even know if the user has an IP address at all. It is the browser that sends it to Google Fonts, which is by the way Google Chrome for the majority, and we use Google Search, Google Drive, Android, and hundreds of services a day that reveal our IPs to Google. As the saying goes: "Google knows you better than you know yourself". You can't stop Google spying on you with a consent dialog.

Can you imagine how many dialogs you should "OK" if the dream of the inventors of GDPR law comes true? Thousands a day. Site visitors already take these popups as a pure annoyance, and click them away without a thought. What do they expect when a visitor is presented with the choice of revealing their IP or not, will they not visit a site because of this? Most people have no idea what an IP is, anyway. How do we expect them to make an educated decision?

Wouldn't it be a better approach if we have such preferences managed by the browser? It's easier to ask once if a user trusts Google Fonts than on every website.

It's a lawyer's world. I remember I had a car to which I had to make a contract every time I got in, promising that I will not be distracted by the entertainment system. I had to do this during driving most of the time. What if I sued the lawmakers for distracting me from driving? ;-)

In the case of heavy-weight data-harvesting services like Google Analytics or Facebook, it's easy to ask the visitor, and avoid loading them if they refuse it. However, with Google Fonts or jQuery "the damage is already done" when the consent dialog pops up, so there's no way of handling it nicely. You either refrain completely from using those services or you "violate the law".


What can you do to avoid "lawyers"?

First off, turn on "Avoid using Content Delivery Networks" under Settings / SkinName / Advanced panel, provided the skin offers this option. A Content Delivery Network is a third-party service that makes it quicker to load some external libraries. Even though the current wave of blackmails does not mention this, it might be their next target, I'm afraid.

Then choose a font that is not from Google, in Settings / SkinName / Site / Typography / Font family. Anything above (including) "Verdana" will do. Choose "[Same as base font]" as the Headline font.

Once ready with the settings, hit "Make album" and "Upload".

Needless to say, this affects only sites in the EU. And it seems, besides Germany nowhere has taken this so seriously.

We are currently working on a solution that loads those fonts from Google during the upload process to the target site, therefore no visitor IPs will be disclosed to Google.

Have a nice day,

Let your galleries speak!


With the freshly released jAlbum 28, your galleries can speak! Each image can now have an audio clip associated with it that plays automatically as you move through the gallery. This is great for instructional type galleries like this one, or why not spice up your birds gallery with chirping bird sounds? You can record audio from within jAlbum or add existing audio files. jAlbum compresses the audio to roughly 10% of its original size to ensure that audio clips both save disk space and bandwidth. (The currently supported audio formats are mp3, m4a and wav.)

We’ve naturally updated our most popular skins to support audio clips, including "Tiger", "PhotoBlogger", "Projector", "Story" and "Minimal", but you’ll also find some 3rd party skins supporting audio clips.

View explanatory galleryApart from providing play / pause buttons to control audio playback, our skins also ensure that the page flipping in "slide show" mode respects the duration of the audio clips.

Curious?, let this explanatory gallery tell you, using my voice, how to add audio clips to your galleries with jAlbum 28!


Download jAlbum 28 →

As always, you can find the full list of improvements and fixes in our release notes.

Celebrating 20 years

This year we’re actually celebrating jAlbum’s 20th anniversary! Very few software titles have such a life span. When I released jAlbum back in February 2002, there was no social media. If you wanted to share images over the web, you needed your own site. That’s no longer the case, and today we face competition from software giants offering “free” image sharing everywhere, usually in “the cloud”.

How can we still be around, one might ask? I think it boils down to three key factors: integrity, convenience and expression:

Integrity: With jAlbum, you’re in control of your image sharing. You never need to rely on one single sharing service. It’s a future proof solution, or to put it bluntly: Your galleries will work even if we go out of business.

Convenience: Being a desktop software, once set up, making regular updates to large galleries is quick and easy.

Expression: Not all web sites look alike, so why should your galleries? With jAlbum, you can customize the visuals and functionality of your galleries to your liking.

I guess you probably choose jAlbum for one of these reasons, and you’re not alone. To date, independent data from shows jAlbum galleries to be present on over 120 million web pages, and this is only counting galleries that have kept credit links to us. We frankly don’t even know how many galleries there are in total, and that’s one of the points.

Thank you for choosing jAlbum!

The 1st jAlbum gallery ever

Coming home from a ski trip back in January 2002, I had 120 images to share. Finding no suitable solution, I decided to write my own. It became jAlbum 1.0 and was released in February 2002.

Enjoy the first gallery, The ski trip →.

Warm regards,

Merry Christmas. jAlbum 26 is free!



Yes, it's true. For the first time in a decade we're offering jAlbum for free*.

Back in 2012, jAlbum went from freeware to be offered under a 30 day trial. This has worked out fairly well (hey, we’re still around...), but we think that people like you and I are far more positive to exploring software without time restrictions. (Just look at how most mobile Apps are made available for instance). In jAlbum 26, the time restriction is gone.




There are instead some functional limitations*, but not to the point of making jAlbum useless – You can make smaller sized galleries in 100 different designs straight out of the box AND download additional skins for even more designs. Here is how we think, our “business model” if you wish:

  1. Get as many people as possible to discover jAlbum and see it’s advantages: Integrity, customisable design and ease of use
  2. Offer additional functionality at a reasonable cost
  3. Offer web space for those that don’t have their own web hosting

The future will tell if this was our best or dumbest move ;-).

Merry Christmas everyone! Get jAlbum 26 today!

* Functional limitations of jAlbum Free:

  • There is a limit of max 24 images or videos per gallery.
  • Galleries can be customized through skin and style choices only. jAlbum’s settings window is “read-only”. (You can see what’s available, but it won’t affect the gallery).
  • Discrete “powered by” credit links are generated



How database-driven skins work

Simple web photo albums put all images (a.k.a thumbnails) on an HTML page and offer to view them in larger size either on the same page (dynamic) or on a separate “slide” page (static). However, when a gallery author wants to enrich the album with advanced functions – like search or tags – using a database will be unavoidable, because plain HTML pages cannot be used for storing data. Especially not for storing data of other folders.

The so-called SQL database is used the most often all over the web, in tandem with an appropriate database-management software (MySQL, MongoDB, or MariaDB) running on the server. Such databases require a server that is capable of running them – you can’t simply run such services on a PC. These databases also require regular maintenance and backup, which is something most content creators would like to avoid. Therefore we chose the middle ground for jAlbum album's lightweight services – the JSON database model (JavaScript Object Notation) – which does not require server-side database processing. Instead, the database is downloaded by the visitor's browser, and processed by the script running behind the page.

Currently the following skins utilize this JSON database: Tiger (default), Photoblogger, Projector and Story.


This database is generated by jAlbum when you hit Make album. Two versions are made: one that contains all the data of all the folders (deep-data.json), the other is made up of a bare-bones tree (tree.json) and several data1.json files – folder data – distributed over the folders. This allows skins to pick the most appropriate database(s) for the chosen features.

When you run a Make album, all these databases get updated, unless you turn ON Settings / Advanced / Process only updated directories. In this case, the database will get easily corrupted over time, where the tree points to missing folders or the next folder’s links get broken. That’s why we always suggest turning this feature OFF with database-driven skins. Recreating the database on each Make isn’t as a burden as running Make on a fresh album, and generating the scaled images – which I guess is the main motivation behind turning this feature on.

When you do manual uploads, e.g. using an external FTP application, you need to pay attention to updating the root folder’s tree.json and data1.json files besides the currently updated folder. (Naturally, the /res folder also needs to be updated after every skin update, but this is something you have to pay attention to with non-JSON skins too.)

Size matters

While the JSON database brings simplicity, it has disadvantages too. One is you can’t go beyond a certain limit without spoiling the user experience. In an album containing 50 000 images, the JSON database could easily grow as big as 50 MB, which takes some 4 seconds to download on a 100 Mbit/s line. There is an overhead time too while the browser recontructs the database in the memory. That’s not ideal. This is why these JSON-based skins try to mitigate the delay by loading the full database only when the visitor starts a search. On page load, they only load the folder tree (tree.json), and the current folder’s individual database (data1.json). The only function that requires the full database is tag cloud, but the album loads it only after the page composition has finished, in order to avoid delay.

Number of
Database size
/ using gzip
@100 Mbit/s
Processing time
(~20 000 obj/s)
Delay before the
search results appear
(first search only)
10 000 10 MB / 0.6 MB 0.8 s / 0.05 s 0.5 s 0.5–1.3 s
50 000 50 MB / 3 MB 4 s / 0.26 s 2.5 s 3–6 s
100 000 100 MB / 6 MB 8 s / 0.53 s 5 s 6–13 s
500 000 500 MB / 30 MB 40 s / 2.6 s 25 s 28–65 s

These figures depend on a lot of things – intended for comparison.

From this table you can see how important it is turning the server’s GZIP feature on in order to speed up the database in huge albums. A JSON database can be compressed down to 5-6% of its original size! I’d say above some 10-20 thousand images it is essential. If you are hosting albums with us – on – don’t worry, you’re already covered.

If you are using the Tag cloud feature, I’d suggest collecting tags only from the “Current folder” above some 20-30 thousand images, as collecting tags from the whole album might noticeably slow down page load.

Although the Search function doesn’t affect all visitors, those who run a search might face longer delays on very large albums or on a very slow connection. So you might want to turn off search in albums larger than, say, 200 000 images, as the results could appear only after 5-10 secs in the best case.

For the more curious

If you wonder how these databases are built up, you can install a JSON viewer browser extension – I use this for instance – and peek into the database by appending data1.json at the end of the URL or instead of index.html. Useful also in case your album gets broken, and you want to check out if the database looks fine. Here’s one example. (Don’t forget to install the viewer first, otherwise, it will look rather ugly. :) )

Your feedback is welcome,