Privacy
Privacy matters when a tool accepts website addresses. This notice describes the data this application processes, what its cache retains, and what may be visible to other systems involved in a check. You can use the tool without an account. Submit only public URLs you are comfortable sending to the destination and to this service; remove access tokens, personal identifiers, and other secrets before submitting.
URLs and public responses
The server uses your submitted URL to send a HEAD request after validating the URL, DNS answers and public IP address. If needed, it sends one GET to the same page. Only an explicit WordPress generator declaration in the response body can permit one same-origin GET to /wp-json/. One redirect is allowed in total; each destination is revalidated. All requests share a five-second budget and four-request maximum. The destination sees the checker server’s request and IP address. Administrative and sensitive paths, including /wp-admin, /phpinfo.php and /.env, are blocked even in submitted URLs. The checker does not forward your browser cookies, authentication headers, or IP address to the destination.
Result addresses include the submitted URL as a query parameter. Those addresses can appear in your browser history, hosting access logs, or any place you share the link. Result pages carry noindex directives and send a no-referrer policy, but those measures do not make a URL private. This application does not deliberately log submitted targets.
Ten-minute cache
The cache key is a SHA-256 hash of the normalized URL. Stored fields include the result category, reported version, summarized evidence, actual inspected URLs (including their query strings), request methods, response statuses, limitations, and check timestamp. Unknown and failed checks are cached too. Full response bodies and cookie values are discarded. Cache keys normalize hostname case, trailing slashes and fragments. Entries expire after ten minutes and are removed on later checks or approximately once a minute while the process is running. This temporary cache is not a permanent detection history; there is no history account or history endpoint. Provider logs and backups, if enabled by the operator, have separate retention settings.
Temporary host request counters also use hashed identifiers and expire after one minute. When disk storage is available, the application uses a local database controlled by deployment administrators. Otherwise the cache stays in the current server process and is lost when that process stops. The same ten-minute expiry applies; separate server instances do not share the in-memory cache.
Analytics and browser storage
Analytics is not enabled for this deployment. The application includes an optional Plausible integration, which sends no events until the operator configures it. The four interaction events are check_submitted, check_success, check_unknown and copy_command_clicked. The integration sends the page’s origin and path, event names, and a method or result category. It does not send submitted target URLs, query strings, cookie values, or copied commands.
When analytics is enabled, Plausible also receives the browser’s network request and user-agent. See the Plausible data policy. The app sets no tracking cookie. A session-storage flag prevents duplicate result events in the same browser session and does not contain the submitted URL.
Questions and project scope
Read about the project, return to the PHP version checker, or review manual verification methods. The deployment operator manages hosting access, logs, and any analytics configuration.