Evidence first.
Certainty has limits.

What happens when you analyze a package?

1. Resolve a version. The npm registry identifies a concrete version for your package name or version range.
2. Build the dependency graph. We resolve runtime dependencies with package scripts disabled. We inspect up to 26 packages and traverse up to four dependency levels. The dependency resolver may do additional work before those inspection limits apply.
3. Inspect archives. We extract package files and inspect up to 160 files for the root scan and 45 per dependency. File-size and parser limits can reduce coverage.
4. Classify signals. Manifest entry points and detected APIs are compared against coarse capability profiles for each runtime.
5. Save the result. A completed analysis creates a public report snapshot. Opening a saved report only reads that snapshot; it never refreshes or runs a scan automatically.

Supported runtime profiles

• Browser
• Node.js
• Bun
• Deno
• Cloudflare Workers
• Vercel Edge
• Vite SSR

These are broad profiles, not certifications for particular runtime versions. Compatibility flags, permissions, bundlers, platforms, and deployment settings can change real behavior. Vite SSR is treated as a Node-based server environment; browser SSR is not applicable.

Four dimensions, with source evidence

Import

Entry points and module formats that may affect loading a package.

Execute

Signals such as native addons and dynamic code that may affect execution.

APIs

Detected runtime-specific APIs, including selected Node built-ins.

SSR

Signals relevant to server-side rendering in the chosen profile.

Findings identify the package chain, file, reason, confidence, and approximate reachability. Package code is never evaluated or executed.

What the labels and score mean

• Likely compatible: no concerning blocker detected in the inspected scope. This is not verified support.
• Potential issue: a signal needs review; it may be unreachable, optional, or handled by your build.
• Likely incompatible: a stronger conflicting signal was found in a selected direct entry.
• Unknown: inspection is incomplete or the available evidence is insufficient.

The score is a heuristic summary of dimension statuses, not a percentage probability or benchmark. Confidence is reduced when the dependency graph or file scan is truncated.

Known limitations

• No runtime tests, sandbox execution, or verification against deployed applications.
• Transitive reachability, tree shaking, conditional code, generated files, export subpaths, and computed imports are only approximated or partially handled.
• Optional dependencies are included with lower-confidence warnings; platform selection is not resolved. Peer and development dependencies are not scanned as normal runtime dependencies.
• Native addons and CommonJS behavior vary by runtime version, platform, flags, and tooling.
• Parser failures, unavailable archives, size limits, and graph caps can hide issues. Both false positives and false negatives are possible.

Confirm consequential findings in your exact runtime and deployment configuration before choosing or rejecting a package.

Versions, freshness, and public reports

The analysis cache lasts seven days. Saved report links preserve the original package version, analysis date, and findings beyond that cache lifetime. Older snapshots may reflect older rules or capability assumptions. A fresh analysis can produce a new report; existing report URLs do not change.

Reports cover public npm packages and are publicly readable. Never submit credentials or private registry URLs. Refreshes happen only when someone explicitly requests an analysis, subject to API limits.