Free online tool
Check a dropped npm tarball before you install it
Drop a .tgz package file you were handed — vendored, private, or from an untrusted source — and inspect it before anything runs. The tool gunzips the file in your browser, lists every file inside, highlights the package.json install scripts (preinstall, install, postinstall), and flags binaries, .env files, obfuscation markers, and size anomalies — with the install-script contents shown for reading first. Nothing is uploaded, installed, or executed.
Quick answer
Quick answer
Drop a .tgz or .tar.gz package up to 25 MB and this tool inspects it in your browser: install scripts, suspicious code, binaries and leaked secrets, each with a plain explanation. You get a Safe, Suspicious or Risky verdict — but it is a static scan, not a security audit, so a clean result never guarantees a package is safe.
Open the interactive npm Tarball Inspector
The interactive tool loads in the page. Enable JavaScript to enter data, process content, and download results.
Worked example — risky sample tarball
The built-in risky sample, as scanned by the tool.
| File | sample-risky.tgz |
|---|---|
| Verdict | Risky — 23 points |
| Flags found | preinstall + postinstall scripts, eval, child_process, network call, base64 blob, obfuscation, .env file, binary |
| What to do | Do not install; delete or quarantine it |
What each flag means
| Flag | What it means | Risk |
|---|---|---|
| preinstall / install / postinstall | A script that runs automatically when the package installs | High |
| eval() or new Function() | Builds code from a string at runtime | High |
| child_process | Can run shell commands on your machine | High |
| .env file | Secrets bundled inside the package | High |
| npm token in .npmrc | An auth token anyone with the tarball can use | High |
| Network call | Code that reaches out to the internet | Medium |
| Long base64 blob | A payload smuggled past a quick read | Medium |
| Obfuscation markers | Code that is unreadable on purpose | Medium |
| Binary file | Compiled code that cannot be read — listed, not analysed | Medium |
| No package.json | No name, version, or script list to check | Medium |
| Very large file | One file over 1 MB — a place to hide a payload | Low |
| Many dependencies | More than 50 dependencies widen the attack surface | Low |
What to do next
| Verdict | What it means | What to do |
|---|---|---|
| Safe | No flags found | Still check the source, then install normally |
| Suspicious | Something unusual is present | Read the install scripts, then install only on a throwaway machine |
| Risky | Serious markers found | Do not install — delete it or quarantine and ask the sender |
About this tool
About the npm Tarball Inspector
Drop a .tgz package file you were handed — vendored, private, or from an untrusted source — and inspect it before anything runs. The tool gunzips the file in your browser, lists every file inside, highlights the package.json install scripts (preinstall, install, postinstall), and flags binaries, .env files, obfuscation markers, and size anomalies — with the install-script contents shown for reading first. Nothing is uploaded, installed, or executed.
Detailed guide
How to get useful results from npm Tarball Inspector
What an npm tarball can hide
An npm package is not just code. When you run npm install, the package's preinstall, install, and postinstall scripts run automatically — with your user's permissions, on your machine, before you have read a line of the code. A tarball handed to you outside the registry can also carry a .env file full of secrets, a binary you cannot read, or code that phones home the first time it loads. None of that is visible from the file name.
Most tarballs are harmless — a vendor's private package, a contractor's build, a pinned version you saved yourself — and most of the flags on this page are rare in ordinary packages. But the same install hooks that make packages convenient are the ones supply-chain attackers abuse: after the August 2026 npm incidents, a package that runs code at install time is exactly the thing to read before you trust it.
How the inspector reads a .tgz without installing it
The tool never installs the package and never runs anything inside it. It reads the file's bytes with the File API, gunzips them with the browser's built-in DecompressionStream, then parses the tar stream by hand — tar is a simple 512-byte-block format, with a name, an octal size, and a type flag per header. From the entries it extracts package.json and the small text files, and lists the rest without storing their contents.
The scan then reads the scripts section of package.json, looks for install hooks, and string-scans the JavaScript files for a fixed pattern table: eval and new Function, child_process, network calls, long base64 blobs, and obfuscation markers. Binaries are listed by extension and by their contents, .env files are called out by name, and every finding is tied to the file it sits in. Everything happens in your browser tab.
What each flag means
Install scripts are the biggest one: preinstall, install, and postinstall all run automatically at install time, which is why each is flagged high and its contents are shown for reading before anything runs. eval() and new Function() are high too — they build code from a string at runtime, so a static scan cannot see what the code will actually do. child_process is high because a package that only formats text has no reason to spawn shell commands.
Some flags are less certain. A network call is medium — a small utility rarely needs the network, but some packages do. A long base64 blob is medium because it is how payloads are smuggled past a quick read. Obfuscation markers are medium: machine-renamed identifiers like _0x1a2b mean the code is unreadable on purpose, which is exactly what a reviewer cannot verify. A .env file is high — real packages never ship one — and a token in .npmrc is high because anyone with the tarball can publish as that account.
How the verdict is worked out
Every flag carries points: high-severity flags are worth 3, medium ones 2, low ones 1, and informational notes 0. A tarball with no flags scores 0 and gets a Safe verdict. A score of 1 to 3 is Suspicious — something unusual is present, but it may have an innocent explanation. A score of 4 or more is Risky — the package has multiple serious markers, or one flag that alone is enough to be dangerous.
The score is deliberately simple and shown in the report, so you can see exactly why a tarball got its verdict. A lone large file adds only 1 point — a dataset or a font is a plausible reason for it. A single install script alone scores 3 and reads Suspicious, because a script that runs at install time is worth a read even when it turns out to be innocent. A package with a preinstall script, eval, and a .env file scores 9, and there is no innocent reading of that trio.
What to do next, by verdict
Safe means nothing was found — but it is not a guarantee, so still check where the tarball came from before installing it, and prefer the registry version of the same package when one exists. Suspicious means something unusual is present: read the install scripts shown in the report, check the flagged files, and do not install it on a machine that holds real secrets or credentials.
Risky means the package has serious markers — install scripts plus eval, a .env file, a binary, or several of those at once. Do not install it. Delete the tarball, or quarantine it and ask the person who sent it to explain the flags, with the copied report attached. If the package came from a vendor or contractor, ask for the source repository and a registry-published version instead of a hand-delivered file.
What this check cannot see
This is a static scan of a dropped file, not a security audit. It reads the file list, package.json, and the text of small scripts — it does not run code, decode base64 blobs, or know whether a script is malicious. Binaries are listed, not analysed: a .node or .exe file could do anything, and this scan cannot tell you what. A script over 256 KB is listed but not scanned, so a very large script escapes the pattern table.
Obfuscation is an arms race: a determined attacker can hide indicators from any static scan, and a package can also fetch its real payload from the network at install time, which no offline scan can see. That is why a clean result must never be read as proof a package is safe — it only means this scan found nothing. The tool is a first triage step, not a verdict on the package's safety: use it alongside the registry version, the source repository, and the oldest security check of all, whether you expected the file.
Who checks a tarball before installing it
Developers handed a package outside the public registry do this check every day — usually by hand: npm pack, tar -tzf, read package.json, look for install scripts, eval, base64, and network calls. Published-package checkers like npxray cover packages already on the registry, with registry metadata a dropped file never has. This tool brings the same first step to the dropped file itself: a vendor drop, a contractor's package, or a just-run-this attachment.
It also fits the rest of this site's privacy tools. The Lockfile Drift Checker catches a package.json that drifted from its lockfile, the Data Anonymizer redacts text before you paste it, and this inspector checks a package before you install it. None of them uploads anything — the file never leaves your tab — which matters most exactly when the file is the thing you do not trust.
Quick guide
How to use this tool
- 01Drop a .tgz or .tar.gz file onto the upload area, or browse to choose one — up to 25 MB.
- 02The tool gunzips the file in your browser, parses the tar entries, and reads package.json and the small scripts.
- 03Read the verdict — Safe, Suspicious, or Risky — and the points behind it.
- 04Open each finding to see what it means and which file it sits in, and read the install scripts before anything runs.
- 05Copy the report, then follow the next step for the verdict — install, investigate, or delete.
Capabilities
Features and supported formats
- Gunzip and parse a .tgz or .tar.gz in your browser with the built-in DecompressionStream — no upload, no install, nothing runs.
- Highlights package.json install scripts (preinstall, install, postinstall) and shows their contents for reading before anything runs.
- Flags eval, child_process, network calls, long base64 blobs, and obfuscation markers in the package's scripts.
- Calls out .env files, npm tokens in .npmrc, binaries, and size anomalies, with the file each flag sits in.
- Scores each flag and explains the verdict — Safe, Suspicious, or Risky — in plain English.
- Lists every file in the tarball with its size, so you can see what you are about to install.
Supported formats
Input: one .tgz or .tar.gz file, up to 25 MB. Output: an on-screen report — verdict, score, findings with file names, install-script contents, binary and .env lists, and the full file list — with a copyable text report. Nothing is downloaded unless you copy it.
Answers
Frequently asked questions
Does the npm Tarball Inspector upload my .tgz file?
No. The file is read with the File API, gunzipped, and inspected only in your browser tab. Nothing is sent to a server, and the package never leaves your device.
Is a Safe verdict a guarantee that the package is safe?
No. This is a static scan of a dropped file, not a security audit. A Safe result means this scan found no indicators — it does not prove the package is harmless. A determined attacker can hide behaviour from any static scan, so still check where the tarball came from.
What is an install script, and why does it matter?
Install scripts are commands in package.json — preinstall, install, and postinstall — that npm runs automatically when a package is installed, with your user's permissions. A malicious install script can run anything on your machine before you read a line of the package's code, which is why this tool shows the script contents before anything runs.
Why is eval() flagged if ordinary code uses it?
eval() and new Function() turn a string into running code. Some packages use them legitimately, but they are also how obfuscated payloads hide: the real behaviour is built from a string only when the code runs, so a static scan cannot see what it will do. The tool flags it as high severity and lets you judge the file.
What is the risk of a .env file in a package?
A .env file holds secrets — API keys, passwords, tokens. Bundled inside a tarball, anyone who receives the file gets those secrets. Real packages never ship .env files, so one inside a package is a serious leak, and the secrets in it should be rotated.
Can the tool check a package already on npm?
This tool is for a dropped file, not a registry lookup — it never sees registry metadata. For a published package, checkers like npxray cover the registry version with its metadata and verdict. If you have both, check the published version there and the dropped file here, and compare them.
What is the file size limit?
One .tgz or .tar.gz at a time, up to 25 MB. Larger files are refused before any reading starts, so a huge file cannot freeze your tab. Scripts over 256 KB are listed but not scanned.
Does the tool install or run the package?
Never. It reads the file list, package.json, and the text of small scripts, and produces a text report. Nothing inside the tarball is installed or executed, and no code from the package ever runs in your browser.
Why are binaries only listed, not analysed?
A binary file (.node, .exe, .dll, .so) is compiled machine code, not readable source. This tool lists binaries with their sizes so you know they exist, but it cannot inspect what they do — a binary in an untrusted tarball is a reason to stop and ask the sender for the source.
What should I do with a Risky tarball?
Do not install it. Delete it, or quarantine it and ask the person who sent it to explain the flags, with the copied report attached. Ask for the source repository and a registry-published version instead of a hand-delivered file.
Does this replace npm audit or a security review?
No. It is a first triage step for a file someone handed you. npm audit covers known vulnerabilities in registry packages, and a real review reads the source — this tool tells you which files deserve that read, and whether anything runs before you get the chance.
Can I use it on my phone?
Yes. The file picker works on mobile browsers, and the whole check runs in the tab. Pick the .tgz from your downloads or mail app and the report appears in seconds.