User-agent strings are weird. They inform the server which application is communicating with them. In the case of a web browser, this string can contain the name and version of the browser, but also information about the operating system and the device on which the browser is running.

But browsers lie. They lie a lot, sometimes for historical reasons and sometimes for compatibility reasons. And sometimes, because they want to limit the information in the user-agent string to reduce the fingerprinting surface and improve the privacy of the user. I’ve written about this extensively in the “The problem with User-Agent strings” series of articles.

This article is a tiny update about what is currently happening with the upcoming release of Safari 26 on iOS, iPadOS and macOS. And this release is particularly interesting because Apple decided to skip a whole bunch of versions for marketing reasons. In the past, the major version was increased every year. In the new scheme, the major version is the year in which the browser is released, plus one. The previous version of Safari was version 18.6. The latest version is Safari 26.0, corresponding to the current year, 2025. Totally makes sense, right?

Continue reading “The User-Agent string of Safari on iOS 26 and macOS 26”

Receipt printers are a complicated subject because of many variables. There are many different types of printers and ways to connect them, but this article will help you navigate most pitfalls.

The answers and suggestions in this article are all based on my libraries, which are open-source and freely available for anyone to use and experiment with. They are all part of the same family and work together, but of course you can also pick and choose some individual components.

Now I am not going to explain how these libraries are used, they have proper documentation. Also in the future I will write some more detailed articles about how these libraries will work together with some example code. So watch this space!

Continue reading “Receipt Printers 101”

This is the sixth and final chapter of “The problem with User-Agent strings “. In the previous chapters, we’ve learned that the User-Agent string is something that web developers should handle with care. Handle with extreme care because it could blow up in your face at any time. But if you knew what you did, you could use it to get somewhat reliable information. We’ve also learned this changed during the last few years due to User-Agent reduction and compatibility issues. But at least there is a modern replacement: User-Agent Client Hints.

In this chapter, we’ll examine the current state of browser detection, whether it is accurate, and whether we should rely on it.

Continue reading “Should we rely on browser detection?”

This is the fifth chapter of “The problem with User-Agent strings“. In the previous parts, we examined the history of the User-Agent string and browser vendors’ efforts to reduce its information. Removing details from the User-Agent string made passive fingerprinting much more difficult. 

These efforts have been really effective because we are now in a position where only the browser name, major version of the browser, and operating system name are reliable. The rest of the details in the User-Agent string are either definitely fake or potentially fake. In either case, we can’t rely on the data being accurate, so the best option is to ignore it.

But we’ve also seen some use cases where those details are helpful. For example, a download page for an application offering different builds based on CPU architecture or whether or not the operating system is running in 32-bit or 64-bit mode. 

How can we provide this information without sending it over the network with every request to every server we contact? The answer is the User-Agent Client Hints API.

Continue reading “The User-Agent Client Hints API”

In our fourth chapter of “The problem with User-Agent strings” we learn about some of the privacy advances that browsers have made in the last couple of years.

Privacy on the Internet has become much more important over the last decade. All the prominent browser vendors informally agreed to limit the potential user-identifying information in the User Agent string. 

As the creator of a popular browser detection library, I might say that browser vendors have been ‘plotting and scheming’ to reduce the amount of helpful information in the User-Agent string, and that makes my life quite a bit more complicated. 

But no. Privacy is essential, and there are certainly some excellent arguments in favour of this effort. 

Continue reading “User-Agent reduction”

In our third chapter of “The problem with User-Agent strings” we taking a look at the problems you run into when you change something in the User-Agent string.

As I mentioned in the previous instalment of this series, the User-Agent string is built upon layers and layers of lies. Sometimes, when I look at a modern User-Agent string, I feel like an archaeologist digging through the layers and determining what happened by looking at the context.

Despite those lies, we used to be able to tell quite a lot from a User-Agent string. But that has changed in the last couple of years.

Continue reading “Trouble happens when you update a version number”

In our second chapter of “The problem with User-Agent strings” is a fascinating story about the browser wars. It’s a tale where the User-Agent string takes centre stage, revealing its unpredictable nature and the need for vigilance when relying on it. 

The tale starts with me buying a new car back in 2016. Now, I didn’t pick this car—a Volvo V60—because it had an entertainment system with a built-in browser, but it definitely was one of the first things I checked out after I took it home. Priorities.

Nowadays, having a proper browser in your car isn’t a big deal, but it was still relatively rare back then. When I got home, I put the browser through its paces. And it was horrendous. It was slow. It couldn’t render modern web pages. The one redeeming thing this browser had was its User-Agent string. Or, actually, it’s two User-Agent strings.

Continue reading “A chapter of unnecessary detail”

In our first chapter of “The problem with User-Agent strings” we are taking a deep dive into history and start with the basics of the User-Agent string. 

Our first stop is in 2018, with the release of Firefox 60. There is nothing significant about this specific release—I could have chosen pretty much any version—but we have to start somewhere.

Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0

So what do we have here? At the back of the User-Agent string we can see our browser, Firefox, version 60. It uses the Gecko rendering engine, and we can tell it’s Windows 10 because it uses version 10 of the Windows NT kernel. We see that it uses WOW64, which means it runs as a 32-bit application on a 64-bit version of the operating system. 

Continue reading “A brief history of the User-Agent string”

If you regularly check your website’s analytics, you may have noticed something weird in the past year or two. None of your visitors use Windows 11, and nobody upgraded their computer past macOS 10.15 Catalina. That can’t be right. So what is going on?

Your analytics packages recognise the browser by looking at the User-Agent string. Every request the browser makes includes that string, which contains a lot of information about your computer, the operating system, and your browser. 

Over the last few years, that information has suddenly become less reliable, often giving us fake information. Why is that, and what can we do? And more importantly, do we even need to know these details in the age of evergreen browsers? 

---

To answer those questions, we need to examine the history of the User-Agent string. It is a somewhat complicated story, so I decided to split it into six parts:

• A brief history of the User-Agent string
• A chapter of unnecessary detail
• Trouble happens when you update a version number
• User-Agent reduction
• The User-Agent Client Hints API
• Should we rely on browser detection?

The Modern FrontEnds conference was held last week in London. It wasn’t a small conference, as the website touts over 100 speakers and more than 3000 developers attending. Not only that, the conference had some big sponsors and a hefty ticket price. 

But before the conference even began, I heard about some serious issues with how the organisers treated their speakers. That immediately raises some red flags. After the event, some speakers spoke publicly about their experiences. 

Now, I wasn’t there. I spoke at a different event in London the day before. But I chatted with some of the Modern FrontEnds speakers about this. And it still feels weird commenting about a conference I did not speak at or even attend. So I am not going to do that.

Continue reading “Red flag: Speakers having to cover their own travel”