$
Disk Usage Visualizer
Paste df -h or du output to visualize disk partitions and directory sizes with color-coded bar charts and treemap views.
What does this disk usage visualizer do?
Paste the raw output of df -h or du -sh from any terminal and the tool parses it instantly into color-coded bar charts, with a treemap view for du data. You can sort df partitions by size, usage percentage, or mount point, and du directories are ranked largest-first automatically. It handles human-readable units (K, M, G, T) and turns a wall of text into a picture you can read at a glance.
Why do df and du show different numbers?
This is the classic disk-space puzzle. df asks the filesystem how many blocks are allocated; du walks the directory tree and adds up file sizes. They diverge when a process holds a deleted file open — du can no longer see it, but df still counts the space until the process closes it. Find these with lsof +L1 or lsof | grep deleted, then restart the offending service. Reserved root blocks (5% on ext4 by default) and files hidden under mount points also widen the gap.
How do I find what is eating disk space on Linux?
Start wide, then drill down. Run df -h to identify the full partition, then du -xh --max-depth=1 /path | sort -h to rank its top-level directories. The -x flag is important — it stops du from crossing into other mounted filesystems and double-counting. Repeat one level deeper until you find the culprit, or use ncdu for an interactive terminal version of the same hunt. Paste any of that output here to visualize it.
Why do I get No space left on device with free space showing?
Two common causes. First, inode exhaustion: a filesystem can run out of inodes (often from millions of tiny files, like stale PHP sessions or mail queues) while df -h still shows free gigabytes — check with df -i. Second, reserved blocks: ext4 reserves about 5% for root, so a partition can refuse writes to normal users at 95%. Tune the reserve with tune2fs -m 1 /dev/sda1 on data-only volumes.
Does du measure file size or disk usage?
By default du reports allocated disk blocks, not logical file size — and the two differ. A sparse file (common with VM images and core dumps) can claim to be 50G in ls -lh yet occupy 2G of real blocks. Compare with du --apparent-size to see logical sizes. Hard links are counted only once per du run, and small files each consume at least one full filesystem block, which inflates directories with many tiny files.
How do I safely free disk space?
Target the usual suspects: journalctl --vacuum-size=200M trims systemd logs, docker system prune -a reclaims unused images and build cache, and apt clean or dnf clean all empties package caches. For a giant log a daemon still has open, do not rm it — the space will not return until the process restarts. Use truncate -s 0 /var/log/big.log instead, then fix log rotation so it does not happen again.
Is my df or du output uploaded anywhere?
No. Parsing and rendering happen entirely in your browser with JavaScript — nothing you paste is sent to a server. That makes the tool safe for output from production machines, since df and du output can reveal hostnames, mount layouts, and directory structures you would not want leaving your network. Close the tab and the data is gone.