Request Info Logger
HTTP request metadata capture
This tool is for authorized security testing and educational purposes only. Never use it to gather information without explicit user consent.
Tracking Pixel
Share this URL or embed the image tag. When loaded, request metadata will be captured.
Returns an invisible 1×1 GIF (tracking pixel).
https://image-spy-test.as93.net/pixel/c2aa894a.gif <img src="https://image-spy-test.as93.net/pixel/c2aa894a.gif" /> Captured Requests
Listening for requests
Open the tracking URL in another tab to test
What is this?
A lightweight HTTP request inspector. Generate a tracking pixel or image URL, embed it in an email, webpage, or document, and see exactly what metadata gets exposed when it's loaded — IP address, geolocation, browser, OS, headers, and more.
How it works
Each session creates a unique image endpoint. When a client fetches the image, the server captures the HTTP request headers and resolves the source IP to a location. Results appear here in real time.
Why it exists
Built to test what data email clients and similar services leak when loading remote images. The aim was to help developers evaluate and improve the privacy and security of their platforms.
Exposed Data & Security Guide
When any HTTP client loads a remote resource, the request carries metadata that can identify and profile the sender. This applies to browsers, email clients, messaging apps, document renderers, and anything else that fetches URLs over the network. Below is a breakdown of every data point a server receives, and what developers can do to limit exposure.
What gets exposed
IP Address & Geolocation
X-Forwarded-For,X-Real-IP,CF-Connecting-IP
Every TCP connection exposes the source IP address. Reverse proxies and CDNs forward the original client IP in headers. Combined with a geolocation database, the IP maps to a physical location (typically city-level), ISP, organization, timezone, and approximate coordinates. This is the most privacy-critical data point in any HTTP request — it persists across sessions and cannot be suppressed by the browser.
User-Agent
User-Agent
Identifies the browser name and version, rendering engine, operating system and version, and device type in a single string. Example: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ... Chrome/120.0.0.0. One of the most effective single inputs for browser fingerprinting — the full string often carries enough entropy to uniquely identify a client.
Client Hints
Sec-CH-UA,Sec-CH-UA-Platform,Sec-CH-UA-Mobile
A structured alternative to User-Agent, sent by Chromium browsers. Low-entropy hints (brand, platform, mobile) are included by default on every request. High-entropy hints (Sec-CH-UA-Full-Version-List, Sec-CH-UA-Arch, Sec-CH-UA-Bitness, Sec-CH-UA-Model) require server opt-in via the Accept-CH response header. Provides cleaner, more granular fingerprinting data than the legacy User-Agent string.
Language & Locale
Accept-Language
Lists the user's preferred languages with quality weights, e.g. en-US,en;q=0.9,fr;q=0.8. Reveals nationality, regional variant, and multilingual preferences. This signal persists even when the IP is obscured by a VPN, making it a useful secondary identifier for geographic profiling.
Referer
Referer
Contains the full URL of the page that triggered the request — including path, query parameters, and fragments in older browsers. Can leak internal application state, search queries, session tokens in URLs, and user navigation patterns. Historically one of the most significant privacy concerns in HTTP. Controlled by the Referrer-Policy response header.
Fetch Metadata
Sec-Fetch-Site,Sec-Fetch-Mode,Sec-Fetch-Dest
Browser-generated headers that describe the context of each request. Sec-Fetch-Site indicates the origin relationship (same-origin, same-site, cross-site, none). Sec-Fetch-Mode indicates the request type (navigate, cors, no-cors). Sec-Fetch-Dest specifies what the resource will be used as (document, image, script, etc.). These are useful for server-side resource isolation policies.
Content Negotiation
Accept,Accept-Encoding
Accept lists preferred content types (e.g. text/html, image/avif, image/webp). Accept-Encoding lists supported compression algorithms (gzip, deflate, br, zstd). Different browsers and versions send different combinations and orderings — these contribute to passive fingerprinting by narrowing down the exact browser build and configuration.
Connection & Caching
Connection,Cache-Control,Upgrade-Insecure-Requests
Connection indicates whether the TCP connection should persist (keep-alive). Cache-Control reveals client-side caching preferences and can indicate whether this is a fresh or repeated request. Upgrade-Insecure-Requests: 1 signals that the browser prefers HTTPS resources. Individually low-risk, but each adds to the overall fingerprint surface.
Do-Not-Track
DNT
A deprecated privacy signal where 1 = opt out of tracking. Removed from web standards in 2019 and ignored by the vast majority of services. Its presence (or absence) paradoxically increases fingerprint uniqueness. Functionally succeeded by the Sec-GPC (Global Privacy Control) header, which carries legal weight under CCPA and GDPR.
Host & Origin
Host,Origin
Host identifies the target domain and port — required on every HTTP/1.1+ request. Origin is sent on cross-origin requests and POST submissions, identifying the requesting page's scheme + domain. While typically not a privacy concern for same-origin requests, these headers can leak internal hostnames, non-standard ports, and application architecture when requests cross domain boundaries.
The headers above are what this tool captures. At the transport layer, servers can also observe TLS handshake parameters (protocol version, cipher suite, SNI), TCP characteristics (window size, TTL, options — used by tools like p0f for OS fingerprinting), HTTP protocol version (1.1 vs 2 vs 3/QUIC), and request timing patterns. Additionally, every request header the browser sends — including any added by extensions — appears in the raw headers dump captured by this tool.
Developer mitigations
If you're building an email client, messaging platform, forum, or any application that renders user-supplied content containing remote resources, these are the key defenses against metadata leakage.
- Proxy remote resources through your server
The single most effective mitigation. Fetch external images, fonts, and assets server-side and serve them from your own origin. The end user never makes a direct connection to the third party, so none of their request headers reach the remote server. This is how privacy-focused email services like HEY, Fastmail, and Proton Mail handle remote images.
- Block remote content by default
Don't auto-load external images, fonts, or iframes. Require explicit user action (e.g. a "Load remote images" button). This is the default in most email clients and prevents all metadata leakage until the user opts in. Display a clear placeholder so users know content was blocked.
- Set a strict Referrer-Policy
Add
Referrer-Policy: no-referrerto your server responses (or use a<meta>tag). This prevents the full page URL from leaking in theRefererheader on all outbound requests — including image loads, link clicks, and subresource fetches. - Restrict resource origins with CSP
Deploy a
Content-Security-Policyheader with a restrictiveimg-srcdirective. Start withimg-src 'self'and add trusted domains as needed. This gives you a browser-enforced allowlist that blocks all unauthorized image loads, including tracking pixels injected via user-generated content. - Limit Client Hints delegation
Use the
Permissions-Policyheader to control which origins receive Client Hint headers. Chromium sends low-entropy hints (Sec-CH-UA,Sec-CH-UA-Mobile,Sec-CH-UA-Platform) on all requests by default. SettingPermissions-Policy: ch-ua=()disables this for third-party contexts. - Enforce HTTPS with HSTS
Deploy
Strict-Transport-Securityto ensure all connections use TLS. Without HTTPS, every request header — including cookies, authorization tokens, and session data — is transmitted in plaintext and trivially interceptable. IncludeincludeSubDomainsand consider HSTS preloading. - Sanitize user-generated content
Strip or rewrite URLs in user-submitted HTML before rendering. Replace remote image sources with proxied equivalents or remove them entirely. Remove event handler attributes, script tags, and
data:URIs. Use a well-tested sanitizer library (e.g. DOMPurify) rather than regex-based approaches. - Audit outbound requests regularly
Periodically test what metadata your application leaks when loading remote resources. Use tools like this one, the browser DevTools Network tab, or request-inspection proxies (Burp Suite, mitmproxy). Document your application's request footprint and track changes across releases.
Response headers reference
These headers should be set on HTTP responses served by your application. Each one controls a specific aspect of how the browser handles outbound metadata, resource loading, or cross-origin interactions. Set them at the server or reverse-proxy level for full coverage.
Referrer-Policyno-referrerAlternatives:
strict-origin-when-cross-origin,same-originControls what URL information is sent in the
MDN referenceRefererheader on outbound requests.no-referrerstrips it entirely.strict-origin-when-cross-originsends the full URL for same-origin requests but only the origin for cross-origin — a good default if you need same-origin referrers.same-originsends the full URL only to same-origin destinations.Content-Security-Policyimg-src 'self'; default-src 'self'Alternatives:
img-src 'self' https://cdn.example.comRestricts which origins can serve resources to your page.
MDN referenceimg-srccontrols image loading — set it to'self'to block all third-party images including tracking pixels.default-src 'self'provides a restrictive baseline for all other resource types. Add specific trusted domains as needed.Permissions-Policych-ua=(), ch-ua-platform=(), ch-ua-mobile=()Alternatives:
camera=(), microphone=(), geolocation=()Controls which browser features and Client Hints are available in your page and its embedded contexts. The empty allowlist
MDN reference()disables the feature for all origins including your own. Use(self)to allow your origin only. Also controls access to sensitive APIs like camera, microphone, and geolocation.Strict-Transport-Securitymax-age=63072000; includeSubDomains; preloadAlternatives:
max-age=31536000Forces the browser to use HTTPS for all subsequent requests to your domain. Prevents protocol downgrade attacks and cookie hijacking over insecure connections.
MDN referencemax-ageis in seconds (63072000 = 2 years).includeSubDomainsextends coverage.preloadallows inclusion in browser HSTS preload lists for first-visit protection.X-Content-Type-OptionsnosniffPrevents the browser from MIME-sniffing a response away from the declared
MDN referenceContent-Type. Without this, an attacker could disguise executable content (scripts, HTML) as an image, and the browser might execute it when loaded in certain contexts. Should be set on every response.Cross-Origin-Resource-Policysame-originAlternatives:
same-site,cross-originControls which origins can read your resources.
MDN referencesame-originblocks all cross-origin reads, protecting against data exfiltration via speculative execution attacks (Spectre). Apply to all responses that should not be embedded or fetched cross-origin. Usesame-siteif you need to share resources across subdomains.Cross-Origin-Opener-Policysame-originIsolates your browsing context from cross-origin windows. Prevents cross-origin documents from obtaining a reference to your
MDN referencewindowobject. Required alongsideCross-Origin-Embedder-Policyto enableSharedArrayBufferand high-resolution timers, which are gated behind cross-origin isolation due to Spectre mitigations.X-Frame-OptionsDENYAlternatives:
SAMEORIGINPrevents your page from being embedded in
MDN reference<iframe>,<object>, or<embed>on other sites. Defends against clickjacking attacks.DENYblocks all framing;SAMEORIGINallows framing from the same origin only. The modern replacement isContent-Security-Policy: frame-ancestors 'none', but both should be set for backward compatibility.Cache-Controlno-storeAlternatives:
private, no-cache, must-revalidateControls response caching behavior.
MDN referenceno-storeprevents all caching — use for pages containing sensitive or session-specific data.private, no-cacheallows the browser to cache but requires revalidation on every use. Never serve authenticated or tracking-related content withpubliccaching directives.