Existing URL reports versus new submissions

Comparison Last checked 25 October 2026

Looking up an existing report retrieves information a service already holds; submitting a URL can request new analysis and disclose the address to that service. The interface label alone does not guarantee that a lookup avoids target contact or publication. Check the exact product mode, operation and visibility rules before sharing a sensitive link.

Separate three questions before using a service

First, what leaves your browser? Sending an address to a report service discloses at least that request to the recipient, even if the service never contacts the target. A password-reset token, invitation or signed download can carry access in the address itself. Removing a visible name does not necessarily remove the secret.

Second, does the operation contact the destination? Searching stored evidence, reading a known report and requesting a new browser visit are different operations. A provider may combine them or initiate background collection. “Lookup” is therefore a description to verify in the provider’s documentation, not a general promise of passive behaviour.

Third, who can see what is retained? A public report, an unlisted report and a restricted report have different audiences. The URL, page content, screenshots, downloaded resources and submitter account information may also have different rules. A statement about deleting account details does not establish when a submitted URL or report disappears.

The submission-privacy guide and redaction guide explain how to recognise sensitive address components. The local URL inspector reads address text without turning it into a provider request. That makes it useful for structural questions, but it cannot supply a reputation report or decide whether the destination is trustworthy.

What the documented operations actually say

This dated supplement covers operational fields missing from the policy ledger. It was read on 25 October 2026, without executing the operations. “Retrieves a report” describes a documented endpoint; it is not an independent network observation or a promise that the provider performs no background processing.

VirusTotal’s report-retrieval documentation describes a GET operation⁴. Its Scan URL warning states: “Any IoC submitted or queried via the API will be scanned and added to the VirusTotal dataset”⁵. It also instructs users to keep sensitive or confidential indicators, and those containing personally identifiable information, out of both submissions and queries. Calling an operation a “read” does not cancel that warning or establish that a secret stays outside the standard dataset.

Google Web Risk provides a different distinction. Its Lookup API sends the actual URL to Google’s server; its Update API supports local checks against downloaded hashes, with additional server checks after local matches⁷. These are different architectures. Neither should be relabelled a private scan mode simply because one reduces disclosure of the complete address.

All twenty-two providers in the existing ledger

The table below uses the unchanged 24 October policy ledger. Its audiences and retention limits belong to the product scopes shown there. The workflow column adds only the documented distinctions above or in the cited product pages. Unknown means that this edition did not establish the field; it does not mean that an action is harmless, private or impossible.

The underlying row IDs and all uncertainty notes remain in the ledger. This article neither changes those records nor fills their gaps with assumptions. A compact row cannot carry every exception, so use the selected product scope when interpreting a term such as “Private.” The documented standard service and a separately purchased offering are not interchangeable.

Private, unlisted and stored are separate properties

urlscan distinguishes Public, Unlisted and Private visibility. Unlisted material is available to vetted researchers using its commercial service; a Private scan can be disclosed by sharing its identifier³¹⁷. Cloudflare’s Unlisted mode likewise depends on possession of its scan identifier rather than an authenticated private audience⁶. Those labels cannot be substituted for one another.

VirusTotal’s separate Private Scanning product describes organization-only reports, configurable retention and exclusion from normal third-party sharing, subject to its stated boundaries¹⁸. These promises do not transfer to the standard API merely because the same organization operates both products. Private analysis also has different evidence coverage, so choosing a mode affects more than a report’s audience.

Retention should be attached to the relevant object. Cloudflare states different periods for successful and failed scans⁶. A provider’s browser-cookie lifetime is not its report-retention policy. An absent numerical period remains Unknown even when a page says that data is stored securely or retained as needed. Security language does not supply a deletion deadline.

An existing report still needs care

Consider the made-up address https://example.test/invite?token=REDACTED. The word REDACTED is a placeholder, not a working secret. A report about that altered address would not establish how the original invitation behaves. Redaction is useful for discussing structure, but changing the input can also change what an external service would analyse.

That gives a practical boundary for comparing workflows. Keep the sensitive original out of public notes, describe the question that remains, and distinguish a structural example from evidence about the original destination. Do not claim that a stripped hostname reproduces a token-bearing page. An organisation’s authorised investigation process must decide whether any further disclosure or target contact is appropriate; an empty policy field does not make that decision.

Suppose someone sends you a report identifier rather than the original sensitive URL. That may avoid a new submission, but the report itself can contain the original address or captured content. Its visibility rules still matter. Copying the identifier into a public ticket can expose a record whose access depends on possession of that identifier.

For a useful handoff, describe the operation you actually need: retrieve a specified existing report, compare its observation time, or obtain an authorised new analysis. Record any unresolved fetch or publication behaviour before an action is taken. If the only available workflow would disclose a live token, do not treat an unknown policy as permission to proceed.

Keep a missing report separate from permission to create one. A search can return nothing because no suitable report is available to that account, because the search does not match the stored record, or because the evidence is no longer available. None of those possibilities establishes that creating a public scan is an acceptable fallback. The original task may have authorised only reading existing information.

The same distinction matters in an automated workflow. An integration described as a report viewer should make any transition to a submission explicit in its own specification. Its operator needs to know which input will be sent, which provider mode applies and what evidence is retained. This is a design boundary for handling sensitive information, not a claim that any listed provider or integration implements it. Where the documentation leaves the transition unclear, preserve that uncertainty in the handoff.

This comparison does not recommend a service for handling secrets. It provides a way to identify the unanswered question: target contact, recipient, report audience, retained objects or deletion period. Keep that question visible rather than selecting the most reassuring badge. The result-state reference then helps interpret whatever existing evidence is legitimately available.

Not covered on this page

• Live provider requests, account entitlements or purchased private products.
• A guarantee that an undocumented lookup avoids target contact.
• Confidentiality certification, service rankings or legal advice.
• Uploading sensitive links, bypassing warnings or starting a scan.