Why was I blocked for a while from www.openstreetmap.org with HTTP 429, but only if using Firefox?

Help and support
,
1

Today, when I tried to access the main OpenStreetMap website with my preferred web browser (Firefox 128.0.3) around 16:00 UTC time, I was immediately blocked with the error “429 Too Many Requests”. Up to and including 1 February 2026, I had no trouble accessing the site. And now (16:22 UTC time), I was able to access the site again.

[Because of this issue, I had to temporarily log into my OSM account from my fallback browser (Ungoogled Chromium) to be able to start this topic!]

Were there any recent changes in operation of the OSM website that affect the Firefox browser?

How come it be that it that a “Too many requests” error occurs on my very first HTTP request to the OSM website in weeks? Could it have been caused by browsing cartes OpenStreetMap (site with French OSM style and some other tile layers) beforehand?

2

Hi,
Could be related:

1 Like
3

I’ve been getting the same problem, but it has always worked on a reload. :man_shrugging:

4

This should be fixed. There was a scraper block that was overly broad.

1 Like
5

Nope, error is still there for me. It seems to be an issue specifically with how Firefox stores pages in cache (which is intended to speed up loading of pages and reduce server load, so HTTP 429 is the most ironic error to occur in such a case).

6

See Access blocked on osm.org - #37 by pnorman

Can you open Developer Tools (Control-Shift-I for most) and provide the full request headers and response headers for one of the tile requests, as well as the URL of the page you are browsing from?

last one is known, first two are not

maybe you have some browser/add-on that strips referer/user agent headers?

7

To be clear, this issue is not about map tiles – it is about the entire www.openstreetmap.org site showing a HTTP 429 error instead of loading normally.

8

Yes, but we still need the headers. I can’t reproduce it with my Firefox install.

9

Request headers with some <REDACTED> details in the cookies:

{
	"headers": [
		{
			"name": "Accept",
			"value": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8"
		},
		{
			"name": "Accept-Encoding",
			"value": "gzip, deflate, br, zstd"
		},
		{
			"name": "Accept-Language",
			"value": "de,en;q=0.5"
		},
		{
			"name": "Connection",
			"value": "keep-alive"
		},
		{
			"name": "Cookie",
			"value": "_osm_location=<REDACTED>; _osm_welcome=hide; _osm_directions_engine=fossgis_osrm_foot; _osm_session=<REDACTED>"
		},
		{
			"name": "DNT",
			"value": "1"
		},
		{
			"name": "Host",
			"value": "www.openstreetmap.org"
		},
		{
			"name": "Priority",
			"value": "u=0, i"
		},
		{
			"name": "Sec-Fetch-Dest",
			"value": "document"
		},
		{
			"name": "Sec-Fetch-Mode",
			"value": "navigate"
		},
		{
			"name": "Sec-Fetch-Site",
			"value": "cross-site"
		},
		{
			"name": "Sec-GPC",
			"value": "1"
		},
		{
			"name": "TE",
			"value": "trailers"
		},
		{
			"name": "Upgrade-Insecure-Requests",
			"value": "1"
		},
		{
			"name": "User-Agent",
			"value": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0"
		}
	]
}

Keep in mind that Firefox reports Intel in the User-Agent even though I’m using an Apple Silicon (ARM64) machine.

10

Since March 23, 2026, the issue didn’t occur to me anymore, which likely means that it was fixed on the server side.