Check My IP privacy policy
Read what data Check My IP must receive to answer a request, what the application does not store, and where infrastructure or lookup-provider logs may exist.
The address is necessary for the response
A web server must receive a source address to return a page. The application uses that address to produce the result shown to you. It does not create an account, personal lookup history, advertising profile, or database row for the request.
Operational records
Hosting, proxy, and security providers may retain short-lived request logs needed to operate and defend the service. Those records can include an address, time, requested path, status code, and browser header. Retention and access should be limited to operational needs.
Submitted tool data
Tool forms process inputs for the current response and do not add them to an application database. Do not submit secrets. Raw email headers can contain names and addresses; redact message content before using the header reader.
Analytics and third-party requests
Clicky measures page views and site use for Check My IP. Its tracking request can include the page URL and title, referrer, browser details, screen size, language, interaction data, and an anonymized IP address under Clicky’s default visitor-privacy settings. Clicky states that its default setting does not use tracking cookies. Read the Clicky privacy policy for its current data and opt-out details. An address lookup may also contact a geolocation provider, which receives the queried public address. Source links open external sites under their own privacy terms.
A request-by-request view of data flow
An IP checker cannot answer without receiving an IP address: the network source is required so the server can return the page. The useful privacy question is what happens after receipt. This application uses request data to produce the current response and does not create an account, advertising profile, or application-level lookup-history row. Infrastructure and optional lookup providers remain separate processing boundaries that readers should understand.
Loading an ordinary page
A request normally includes a source address, time, requested path, method, and browser headers needed for HTTP delivery. The homepage calculates basic address facts locally and returns its initial document without waiting for external geolocation. The browser then requests optional public network context for the map and labels. This separation improves initial performance but does not make the enrichment request invisible: the application still needs to submit the queried public address to its configured data provider when enrichment is requested.
Using a diagnostic form
Tool inputs are processed for the current response and are not added to an application database. The operation varies: an address may be parsed, a public name resolved, a public TLS endpoint contacted, a limited HTTPS HEAD request made, or text summarized locally on the server. Client-side pages can inspect only the browser-visible signals shown in their interface. Avoid secrets in every form. In particular, redact email headers and do not submit private keys, authentication headers, tokens, internal-only names, or confidential URLs.
Operational, analytics, and third-party boundaries
Hosting, reverse-proxy, content-delivery, and security providers may retain limited request logs to operate and defend the service. Clicky receives analytics events so the operator can understand page views and site use. Under Clicky’s documented default visitor-privacy settings, those events include an anonymized IP address and do not use tracking cookies; the privacy page links to Clicky’s current policy and opt-out details. Public map tiles and source links are third-party requests subject to those services’ terms. Address-enrichment providers receive the public address queried.
Practical choices for readers
Use only the data necessary for the task and remove private context before sharing a result. A VPN can change the public source visible to sites and shifts trust toward its operator, but accounts, cookies, browser characteristics, and submitted content can remain linkable. Private browsing affects local browser state more than network visibility. The site does not claim anonymity and cannot identify which household member used a shared address. Requests involving provider subscriber records or legal disclosure must go to the relevant operator through an appropriate lawful process.
A practical reading sequence
| Starting point | Reasonable use | Important boundary |
|---|---|---|
| Page request | Source, path, headers | Deliver and protect the service |
| Tool submission | Value entered by the reader | Return the requested calculation or observation |
| IP enrichment | Queried public address | Network-owner and approximate-area context |
| Clicky analytics | Page, referrer, browser, and interaction data | Measure traffic under Clicky’s visitor-privacy settings |
Search pages are marked not for indexing because arbitrary query combinations are temporary navigation views rather than public profiles. API and health endpoints carry crawler controls for the same reason. Canonical editorial pages remain discoverable through ordinary links and the XML sitemap. These search-engine directives reduce duplicate crawling; they are not access controls and should never be treated as a way to protect submitted secrets. Anything sent in a web request must be considered visible to the systems that process that request.
The current public tools do not require an account session to create a lookup history. Clicky states that its default visitor-privacy settings do not use tracking cookies; its script still sends analytics events to Clicky, so blocking that script prevents those measurements. Browser storage and third-party scripts are reviewed whenever functionality changes. A future feature that materially changes collection, retention, sharing, or user choice requires both an implementation review and an update to this page.