dd command generator
I never remember the exact dd incantation. Never. So I built this to spit it out for me. Pick a preset for whatever you’re up to (flashing an ISO to a USB stick, imaging a disk, zeroing a drive, carving out a quick test file), tweak the input and output and block size, then copy a command with every operand spelled out so you actually know what each piece is doing. And because dd will happily nuke a device without so much as a “you sure?”, the tool throws a loud warning the second your output points at one. There’s no server behind any of this, just the page itself doing the work on your machine.
of= at the wrong device and it’s gone. Instantly. No prompt, no recycle bin. You don’t get it back. So before you run anything, fire off lsblk or diskutil list and stare at that device letter until you’re actually certain it’s the right one. People don’t call it “disk destroyer” to be funny.lsblk on Linux, diskutil list on macOS. The USB you just plugged in is almost always sitting at the bottom of the list. And /dev/sda is the main disk on most machines, so leave it alone unless wiping your system drive is genuinely the plan.What this dd command generator does
What dd does is dumb and powerful at the same time. It copies bytes block by block between files and devices, treating a whole disk as one long stream of nothing in particular. That’s why it can write a bootable USB or clone a raw partition when a normal file copy just shrugs and gives up. It’s also the exact same reason one typo in the output path can flatten the wrong drive before you’ve finished blinking. So the tool builds the command from presets and labelled fields and explains every operand in plain English. When the target looks scary, it lights up. Then it’s on you to double-check the device before you run it.
dd doesn’t use dashed flags like the rest of the universe, and that alone trips people up. It’s operand=value the whole way down. if= is what you read from, of= is what you write to, bs= sets the block size, count= caps how many blocks get copied. Take the classic USB-flashing line, dd if=image.iso of=/dev/sdX bs=4M status=progress conv=fsync. That reads the ISO, writes it straight onto the raw device in 4 MB chunks, prints progress as it goes, then forces the cache to flush at the end so you don’t yank the stick too early and corrupt the thing.
The operands that matter
| Operand | Meaning |
|---|---|
if= | Input file or device to read from. Use /dev/zero for zeros, /dev/urandom for random data. |
of= | Output file or device to write to. The dangerous one: a device path here is overwritten. |
bs= | Block size for each read/write. Larger blocks (1M, 4M) are much faster for whole-disk work. |
count= | Number of blocks to copy. Combine with bs to limit total size, e.g. bs=1M count=1024 makes 1 GB. |
status=progress | Print a live progress line. Otherwise dd is silent until done. |
conv=fsync | Flush all data to the device before exiting, so the write is actually complete. |
Common jobs
- Flash an ISO to USB:
dd if=linux.iso of=/dev/sdX bs=4M status=progress conv=fsync. Unmount the stick first. Aim at the whole device (/dev/sdb), never a partition (/dev/sdb1). This is the one I reach for most, by a mile. - Back a disk up to an image file:
dd if=/dev/sda of=backup.img bs=64K status=progress. Want it back later? Swap if and of around and you’re restoring. - Zero out a drive:
dd if=/dev/zero of=/dev/sdX bs=1M status=progress. Fine for old spinning rust. On an SSD though, I’d honestly skip dd and reach forblkdiscardor the drive’s own secure-erase, it’s quicker and easier on the flash. Could be I’m overcautious there, but I’d rather not burn write cycles for nothing. - Spin up a test or swap file:
dd if=/dev/zero of=test.img bs=1M count=1024hands you a 1 GB file in seconds.
How to not destroy the wrong disk
Every dd horror story I’ve heard ends the same way. The wrong device in of=. So make it a reflex: run lsblk (Linux) or diskutil list (macOS) right before you fire, then match the size and the model to the drive you actually mean to hit. On Linux your system disk is nearly always /dev/sda or /dev/nvme0n1. The USB you just plugged in grabs the next free letter, usually something like /dev/sdb or /dev/sdc. Don’t point dd at a device as root until you’ve eyeballed that path yourself. A sudo and one fat-fingered letter is plenty to wipe a perfectly healthy drive.
Privacy and how this tool runs
All the work happens in JavaScript, right here in your browser. The paths and device names you type don’t get sent anywhere, and nothing’s logged. I don’t see them. Nobody does. Once the page has loaded you can unplug the network cable and it’ll keep humming along just fine.
Frequently asked questions
How do I write an ISO to a USB drive with dd?
Run dd if=image.iso of=/dev/sdX bs=4M status=progress conv=fsync and swap /dev/sdX for whatever your USB shows up as in lsblk. Unmount it first, but don’t eject it. You still need the device node. Aim at the whole device, never a partition. And wait for conv=fsync to finish flushing before you pull the stick. Pull it early and you’re left with a half-written image and a bad afternoon.
What block size should I use?
For anything whole-disk or USB-shaped, go big. bs=4M runs circles around the puny 512-byte default. When you need an exact size, pick a block that divides cleanly, like bs=1M count=1024 for a tidy 1 GB. There’s no magic number here, honestly. Anywhere from 1M to 4M is fine on basically any hardware you’ll touch today. I just leave it on 4M and stop thinking about it.
What does conv=fsync do and do I need it?
Here’s the trap. Without it, dd will cheerfully tell you it’s done while a chunk of your data is still parked in the kernel’s write cache. conv=fsync forces everything onto the physical device before dd exits, so “done” actually means done. I always add it for removable media. It’s the whole difference between a clean stick and one you quietly corrupted by pulling it two seconds too soon.
How do I see progress while dd runs?
Just tack on status=progress if you’re on GNU coreutils 8.24 or newer, which is pretty much everything shipping now. Stuck on something genuinely ancient? Open a second terminal and poke the process with kill -USR1 $(pgrep ^dd). That nudges dd into spitting out a one-off progress line. Sure beats staring at a frozen cursor, wondering if the thing hung or is just busy.
Is dd the best way to clone a disk?
It’ll do the job, sure. But it copies every block, empty ones included, so it crawls on a big disk. For real cloning I’d reach for partclone or Clonezilla instead, since they only touch the used blocks. And ddrescue is the one you want when a drive is actually dying: it retries the bad spots and logs every sector, so you can pick up where it left off. Keep plain dd for ISOs and little images and the quick one-offs where the overhead just doesn’t matter.
What is the difference between /dev/sdb and /dev/sdb1?
Think of /dev/sdb as the whole drive and /dev/sdb1 as the first room inside it. For a bootable ISO you want the whole drive, because that’s the only way the partition table and the boot sector get written too. Just copying a single filesystem? Then a partition is fair game, go ahead. But flash an ISO onto a partition and you’ll almost always end up with a stick that won’t boot. I’ve watched people burn an hour chasing exactly that, then realize they aimed one character too deep.
Sources & further reading
Related tools and resources
Did this save you a trip to the man page? Here are the other command builders I keep parked on the same shelf.
