Check what your browser can see, then build a fuller Linux report only if you want one
The instant check uses normal browser information. For distro, kernel, CPU model, graphics driver and storage details, copy the visible read-only command, run it yourself, and paste the output back here. Nothing is installed and nothing runs automatically.
Browser-visible system details
This is the information a modern browser is allowed to expose without a Linux scanner.
Read-only terminal report
Use this only when you want details the browser cannot read directly.
Your Linux system report
The cards below are parsed from the text you pasted. Unknown values are left unknown rather than guessed.
Use the result as practical guidance, not as a guarantee for every Linux system. Distribution releases, package names, hardware, filesystems and local configuration can change behavior. Review generated output before using it, back up important data before system changes, and confirm sensitive or destructive operations in your distribution’s current documentation.
Linux has excellent system-information commands, but the useful details are scattered across several utilities. This checker gives you two safe paths: a quick browser view for information the browser is allowed to expose, and a fuller report analyzer for details you deliberately copy from a read-only terminal command.
The distinction matters. A web page cannot simply request permission to read /etc/os-release, PCI devices, mounted filesystems or kernel drivers. Rather than pretend otherwise, the checker shows exactly what it can see and gives you a visible command for the information that must come from Linux itself.
What the browser check can—and cannot—see
A modern browser may expose the platform family, logical processor count, screen size, language, timezone, battery status and a graphics renderer through WebGL. Some browsers also expose an approximate device-memory value. These APIs are deliberately limited for privacy, and support varies, so an unavailable value is reported as unknown rather than inferred.
The browser cannot reliably identify whether Linux is Ubuntu, Fedora, Arch or Mint, nor can it enumerate kernel modules, storage devices or package managers. Those details require local operating-system access that ordinary websites do not receive.
| Detail | Browser check | Full pasted report |
|---|---|---|
| Linux/platform family | Usually | Yes |
| Distribution and version | No | Yes |
| Kernel release | No | Yes |
| CPU model | Usually not | Yes |
| RAM totals | Approximate/limited | Yes |
| GPU and active driver | Renderer may be visible | Yes |
| Disks and filesystems | No | Yes |
| Desktop/session | No | Yes |
What the read-only Linux report collects
The fuller path uses ordinary inspection commands such as cat /etc/os-release, uname, lscpu, free, lspci, lsblk and df. The command is printed on the page before you copy it. There is no downloaded executable, package installation, sudo requirement or automatic upload.
Once pasted back into the page, JavaScript parses the report locally and groups the useful pieces into operating system, processor, memory, graphics, storage and desktop/session sections. If a command is missing on a minimal distribution, the rest of the report can still be analyzed.
Privacy mode is there for a reason
System reports are easy to overshare. Usernames, home-directory paths, private IP addresses and MAC addresses can identify more than you intended when a report is copied into a public forum. Privacy mode masks common patterns before the formatted report is shown.
Redaction is a convenience, not a security boundary. Read the final report before posting it publicly, particularly on work systems or machines with unusual mount paths, hostnames or network configuration.
How to read CPU, memory and graphics information
CPU model and thread count tell you what the kernel sees, while memory output separates total, used, available and swap figures. “Available” memory is usually more useful than “free” memory because Linux deliberately uses otherwise-idle RAM for caches that can be reclaimed when applications need it.
Graphics output is most useful when the GPU name is paired with the active kernel driver. Seeing an NVIDIA, AMD or Intel device without the expected driver bound to it is a different problem from having a driver loaded but an application using the wrong renderer.
Storage information needs context
lsblk describes block devices, partitions, filesystem types and mount points; df reports filesystem capacity and usage. They answer related but different questions. A drive can have free unpartitioned capacity that does not appear as free space inside an existing filesystem, and a filesystem can be almost full even when another disk in the machine is empty.
For Btrfs, ZFS, LVM, RAID or encrypted setups, a short generic report cannot describe every layer. Use the checker as a map of what is visible, then move to filesystem-specific tools when the layout is more complex.
A practical way to use the report when troubleshooting
Start by saving the report before changing drivers, kernels or storage settings. If a later change causes trouble, you have a simple before-and-after reference for the kernel, GPU driver, memory, mounts and desktop session. That is often more useful than trying to remember what changed.
The checker does not label a machine “healthy” merely because every field is present. Hardware health, filesystem integrity and application stability require dedicated tests; this page is an inventory and context tool, not a hardware certification.
Official references and further reading
Related TechRefreshing tools
If this result raises another Linux question, the related tools below can take the next step without making you repeat the same research from scratch. Only tools that are already published are shown.