See the exact HTTP headers your browser or client sends — a clean, searchable dump for debugging scrapers, custom clients, and curl — then export them as ready-to-run Python, Node.js, cURL, or fetch() code. Nothing stored.
These are the HTTP request headers your browser (or curl, or any client) sent to our server on this request — reflected straight back to you. Useful for debugging what your scraper, custom client, or browser is actually transmitting. Scroll down to export them as ready-to-run code — Python, Node.js, cURL, or fetch(). Nothing is stored.
Your browser’s sendable headers, formatted as a ready-to-run request in your language of choice. Pick a tab and copy. CDN-added and IP-bearing headers are left out — those aren’t headers a client should set.
Every time your browser or client requests a page, it sends a set of request headers alongside the request — small key-value lines that describe who’s asking and what they can accept. The server reads them to decide how to respond. This tool simply shows you the headers your client sent us, so you can see exactly what your browser, curl command, or scraping engine is transmitting.
User-Agent identifies your browser and operating system family — the most-read header, and the one scrapers most often need to set correctly. Accept-Language tells servers your preferred languages. Sec-CH-UA client hints report your browser brand, version, and platform (a modern, more structured companion to User-Agent). Accept and Accept-Encoding declare the content types and compression your client can handle.
You’ll see headers like CF-Connecting-IP and X-Forwarded-For — these carry your own public IP as it reached us through the CDN. That’s the same address shown on our homepage; it’s your request data, reflected to you. If you’re testing a proxy or VPN, comparing what appears here against your real IP is a quick sanity check that your client is routing the way you expect.
When a scraper gets blocked or a custom HTTP client behaves unexpectedly, the first question is “what am I actually sending?” A header that’s missing, malformed, or obviously automated (a default library User-Agent, say) is often the culprit. Hitting this page with your client — or curl -s checkmyipnow.com/api/headers from a script — shows you the exact set the server received, with no guesswork.
Related: Developer API & endpoints · What a WebRTC leak is