Download

Independent guide · English

One USB stick. Many bootable images.

Ventoy is a multiboot tool: install it once, then drop ISO, WIM, IMG, or VHD(X) files onto the drive—no need to wipe and re-flash for every new OS or rescue disc. This page explains how it works, how to install it safely, and how others solved common problems. Jump to step-by-step installation, download installers, or troubleshooting fixes.

Get Ventoy Installation steps

Always verify checksums for any ISO or installer package you use.

Overview — what problem does Ventoy solve?

Traditional USB tools often write one image at a time. If you need Windows today, Linux tomorrow, and a memory-test ISO on the weekend, you end up reformatting or juggling multiple sticks. Ventoy keeps a small EFI boot partition and a large data partition: you copy files like normal documents, boot, and pick an entry from the menu. Before you start, read requirements and safety and follow Windows or Linux installation.

Recursive discovery

ISOs can live in folders and subfolders; Ventoy scans the first (large) partition and lists images—alphabetically by default. Plugins can limit search paths.

UEFI & Legacy

Supports x86 Legacy BIOS, IA32 UEFI, x86_64 UEFI, ARM64 UEFI, and MIPS64EL UEFI. Secure Boot is supported in recent versions when configured correctly.

Also a normal drive

The big partition can store ordinary files alongside images; everyday use does not break Ventoy as long as the filesystem rules (e.g. cluster size) are respected.

Features power users care about

  • In-place updates refresh Ventoy’s boot code without wiping your ISO collection.
  • Plugins & ventoy.json customize themes, passwords, persistence (where supported), and search roots under /ventoy/ventoy.json.
  • .ventoyignore in a folder stops that tree from appearing in the boot menu—handy for archives or private data.
  • Windows CLI since 1.0.86 and Linux GUI options (GTK/Qt/WebUI) for those who avoid clicking through Explorer.
  • Compatibility varies by image—check project notes for tested ISOs and edge cases before assuming an image will chain-load.
Illustration of Ventoy partition layout: large data partition plus small EFI boot partition

After installation you typically see two partitions: a small EFI (VTOYEFI) region and a larger exFAT (or user-chosen) filesystem for images.

Requirements & safety checklist

Before you install

  • Back up anything on the target disk—installation formats the device.
  • On Windows, run Ventoy2Disk as administrator; close tools that mount Linux filesystems on the stick.
  • Prefer a quality USB 3.x drive; fake capacity sticks cause grub shells and random failures.
  • If dual-booting PCs, know whether firmware is UEFI or Legacy—the firmware chooses the mode, not Ventoy.

After you reformat the big partition

You may use FAT32, NTFS, UDF, XFS, ext2/3/4, etc., but cluster size must be ≥ 2048. Example commands (adjust device letters/paths):

format X: /fs:ntfs /q
sudo mkfs -t ext4 /dev/sdX1

Installation — Windows & Linux

These steps cover a typical install; your package version may differ slightly in filenames or dialogs.

Windows (GUI)

  1. Download ventoy-x.x.xx-windows.zip from a source you trust and extract it.
  2. Run Ventoy2Disk.exe (32-bit binary; works on 64-bit Windows). Since 1.0.58, alternate builds exist in altexe—copy the X64/ARM variant up next to the main EXE if needed.
  3. Select the correct USB device. Toggle Show all devices only if you understand you could wipe an internal disk.
  4. Click Install or Update. Updates preserve files on the first partition.
  5. Copy ISO/WIM/IMG/VHD(X) files to the large partition—any folder structure is fine.

If the GUI always fails, try a LiveCD-based install or the Ventoy2Disk troubleshooting notes bundled with your installer.

Linux (CLI)

  1. Download ventoy-x.x.xx-linux.tar.gz and extract.
  2. Run the shell script as root, e.g. sudo sh Ventoy2Disk.sh -i /dev/sdX (replace sdX with your device, not a partition number).
  3. Use -I for forced reinstall, -u for upgrade, -l to print Ventoy info.
  4. Optional flags include -s (Secure Boot support), -g (GPT), and -r SIZE_MB to reserve space at the end of the disk.

GUI options: GTK/Qt or WebUI installers are available in many Linux packages.

Troubleshooting & fixes

Symptoms below appear often in community threads. They are summarized here with practical next steps; cross-check with GitHub issues when you need a precise match for your build.

USB missing in Ventoy2Disk (Windows)
Exit Paragon ExtFS, Dokan, DiskGenius, Intel DSA, and similar mounters. If still missing, use LiveCD/Linux or CLI per docs.
Stuck at “Ventoy scanning files…”
Too many files on the partition—narrow search paths in ventoy.json so Ventoy scans fewer folders.
Dropped into a grub> shell
Often counterfeit USB media or BIOS storage limits. Test the stick and review Legacy BIOS disk-access limits if the machine is older.
Windows 7 installer: “no install media found”
Frequently missing USB 3.0 drivers inside the ISO; try a USB 2.0 port or integrate drivers per Microsoft/Ventoy discussions.
Secure Boot errors in UEFI
Use a current Ventoy build and enable Secure Boot support during install if your firmware requires it; you may need to enroll keys in UEFI.
Checklist graphic for Ventoy troubleshooting steps

Verify checksums for large ISOs before assuming Ventoy is at fault.

Real-world scenarios (community-style lessons)

These are typical patterns people report—not testimonials of this site. They help you recognize situations faster and search with better keywords (useful for discovery on Google, Bing, and Yandex).

“IT bench workflow: I keep WinPE, Linux live, firmware updater ISOs, and memtest on one 128 GB stick. Clients boot whatever they need; I only refresh individual files.”

Pattern: multi-tool USB without constant re-imaging

“The mystery missing drive: Ventoy2Disk showed nothing until I quit Intel DSA and Paragon services—then the stick appeared instantly.”

Pattern: volume locks on Windows

“Slow menu after hoarding files: I copied entire project backups to the Ventoy partition. Boot scans took forever until I limited search paths in ventoy.json.”

Pattern: huge file trees and scan time

“Linux after boot: I needed the ISO partition inside the running OS—Linux remount behavior explained why the volume looked empty at first.”

Pattern: accessing data partition from Linux
Summary of common Ventoy tips from community practice

Frequently asked questions

Can Ventoy be installed on devices other than small USB sticks?

Yes—USB drives, removable HDDs, SD cards, SATA disks, SSDs, NVMe, and more. Windows lists removable USB-class devices by default; Linux targets a block device you specify. Any install still destroys data on that disk.

How do I know if I booted UEFI or Legacy?

On the Ventoy menu, check the lower-left version line: it shows BIOS, UEFI, IA32, AA64 (ARM64), or MIPS depending on mode. The motherboard firmware decides the mode.

Why is a deleted ISO still listed?

Windows may have moved the file to the Recycle Bin on that volume instead of deleting it completely—empty the bin or shift-delete.

Where does ventoy.json go?

On the first large partition, inside a folder named ventoy—full path /ventoy/ventoy.json. Do not place it on the small VTOYEFI partition.

Download

Installers and release notes are hosted on ventoy.co. Verify checksums after download when they are published with each build.

Download now

Bookmarkable page with the same download link (all languages): ventoy.co/download.html.

  • Source and issues: github.com/ventoy/Ventoy
  • Read the README and bundled docs inside each release package for plugins and advanced options.

Extended reference

Deeper topics & workflows

The blocks below add practical depth—filesystem trade-offs, real roles, security habits, and terminology. They are written to complement the overview and install sections, not repeat them line for line.

Firmware modes: what actually decides Legacy vs UEFI

Ventoy presents a menu after firmware hands control to the USB. Whether that handoff used Legacy BIOS or UEFI is determined by your motherboard settings (CSM on/off, “USB boot mode”, secure boot policy), not by a toggle inside Ventoy’s menu. If an ISO behaves differently in one mode, mirror the same mode you used when the vendor tested that image—mixing UEFI ISO expectations with a Legacy boot path is a frequent source of “it boots but then fails” reports.

Quick firmware checklist

  • Disable Fast Boot on laptops if USB enumeration is flaky.
  • Try another USB port class (2.0 vs 3.x) when installers miss storage drivers.
  • Reset custom boot order after firmware updates—updates sometimes revert to internal disk only.

Why the version line matters

The small build string on the Ventoy screen tells you which architecture and mode you are in. Screenshot or note it when asking for help; mismatched mode descriptions make remote debugging guesswork.

Data partition: picking a filesystem

After installation you may reformat the large partition within Ventoy’s rules (minimum cluster size). Here is a decision-oriented comparison—your OS mix and file sizes should drive the choice.

Filesystem Typical strength Watch out for
exFATLarge ISOs, simple Windows+macOS interchangeSome older Linux tools need extra drivers for write access
NTFSVery large files, Windows-native toolingRepair tools differ across OSes if not cleanly ejected
FAT32Maximum compatibility for small utilities4 GB file size limit—problematic for big ISOs
ext4Linux-first workflows, permissions you understandWindows needs third-party drivers for convenient editing

Role-based USB layouts (examples)

Field technician / helpdesk

Carry one high-quality 64–256 GB stick: a hardware diagnostic ISO, two Linux live environments with different kernels, a firmware update bundle for common vendor models, and a memory-test image. Keep a /tools folder for portable Windows utilities that are not boot images so they do not inflate scan time—use .ventoyignore on heavy archive trees.

Developer / QA

Versioned nightly builds clutter menus—prefix filenames with YYYY-MM-DD_ so alphabetical sorting matches chronological order. For A/B tests, duplicate ISOs with clear suffixes rather than overwriting silently; checksum both before field use.

Education lab coordinator

Standardize one “known good” semester image per bench, keep a secondary slim rescue ISO, and document the expected boot mode (UEFI vs Legacy) on the room poster—students mix modes more often than power users.

Image types beyond “one big ISO”

  • WIM — useful for Windows PE–style workflows; behavior depends on how the WIM was produced and which drivers are injected.
  • VHD / VHDX — handy for prebuilt environments; size and controller expectations still follow the guest OS inside the image.
  • IMG — often raw dumps; treat them like fragile glass—verify integrity and avoid editing on hosts that reorder bytes oddly.

Integrity & supply-chain hygiene

Ventoy can compute hashes at boot when you use its tools—use that for spot checks on slow hotel Wi‑Fi downloads. Separately, prefer publishing your own internal checksum file alongside classroom ISOs so students compare against your mirror, not a random search result.

  • Rotate sticks that travel through untrusted machines; treat them like credentials.
  • Keep a paper copy of critical checksums for air-gapped installs.
  • Never “fix” a suspicious ISO with a random repack from forums—re-download from the original vendor channel.

Hardware notes that are not about “more gigabytes”

USB bridge quality

Cheap adapters throttle sustained reads and overheat—symptoms look like random boot failures, not clear error strings.

SSDs in USB enclosures

Fast for iterative QA; still verify TRIM/idle power behavior on laptops that cut USB power aggressively.

SD cards

Convenient for cameras; random-write performance varies wildly—benchmark before relying on them for huge ISO libraries.

How Ventoy differs from single-flash tools (neutral)

Rufus, balenaEtcher, and dd-style imagers excel at writing one image accurately. Ventoy optimizes for many images over time without re-flashing. Choosing is a workflow question: frequent OS swaps favor Ventoy; one-off media creation may stay simpler with a dedicated flasher.

Glossary

BIOS / UEFI
Firmware interfaces; UEFI is newer and pairs with GPT partitioning in most modern PCs.
CSM
Compatibility Support Module—enables Legacy boot paths on UEFI boards when enabled.
EFI system partition
Small FAT-family partition holding bootloaders; Ventoy maintains its own EFI area separate from your ISO storage.
ISO 9660
Common optical image layout; many Linux ISOs are hybrid and also work as disk images.
Loop device
Linux mechanism to mount image files as block devices—relevant when debugging inside a live OS.
Initrd / initramfs
Early user-space used by many Linux boots; missing firmware blobs here cause “can’t see disk” symptoms.
Secure Boot
UEFI policy that only runs signed bootloaders unless you enroll custom keys.
TPM
Trusted Platform Module—Windows 11 installer may reference it; unrelated to Ventoy’s menu but part of the same session.
Multiboot
Any scheme that selects among multiple OS images; Ventoy is one implementation style.
Persistence
Saving live-OS changes across reboots when the distro supports overlay files or partitions.
Cluster size
Allocation unit on formatted volumes; Ventoy’s data partition must meet minimum cluster rules after reformat.
MBR vs GPT
Partitioning styles; installer flags may set one or the other at Ventoy deployment time.

More questions (expanded)

Can I password-protect the boot menu?

Plugin configuration can add menu passwords in supported setups—treat passwords as a deterrent, not encryption of the whole stick; physical access still matters.

Why does my menu order look “wrong”?

Default ordering is alphabetical; rename files with consistent prefixes or use plugin rules if you need a fixed demo sequence.

Does Ventoy encrypt my files?

No—your ISOs are ordinary files on the partition. Use OS-level encryption or hardware-encrypted drives if policy requires it.

Can I run Ventoy from a read-only kiosk profile?

Installers need write access to the destination disk; prepare sticks on a full admin session, then lock down clients separately.

What if antivirus quarantines Ventoy2Disk?

Low-level disk tools sometimes trigger heuristics; verify signatures from the project release, temporarily exclude the download folder, or install from Linux.

How do I document a build for coworkers?

Record Ventoy build string, firmware mode, partition style, filesystem, and checksums of every ISO—future you will not remember the “obvious” defaults.

Common pitfalls (short list)

  1. Dragging ISOs into cloud-sync folders that re-download partial files mid-copy.
  2. Mixing personal documents into the same directory tree Ventoy scans—use folders + ignore rules.
  3. Teaching new users to “always pick the first menu entry”—train them to read filenames every time.
  4. Assuming Secure Boot settings survived a motherboard battery failure—re-check after hardware service.

Keeping the stick maintainable at scale

When more than one person updates the same USB, agree on a naming scheme, a retirement policy for old ISOs, and a monthly checksum audit. For distributed teams, ship a small text manifest (SHA256SUMS) on the partition so recipients verify before imaging lab machines.

“We stopped emailing ‘latest ISO’ links and instead pinned exact filenames in our runbook—support tickets dropped because everyone booted the same bytes.”

Paraphrased ops pattern from public multiboot discussions

Menu readability & stress scenarios

Boot menus are often read under poor lighting or during incidents. Short, descriptive filenames beat clever abbreviations. If you theme the UI, keep contrast high; what looks stylish in a screenshot may be unreadable on a dim projector.

Ventoy vs PXE / network install servers

Datacenter PXE chains are unbeatable when every machine trusts your DHCP scope. Ventoy shines where there is no network, air gaps, or guest networks block PXE. Many teams use both: PXE for fleet rollouts, Ventoy for one-off bench diagnostics.

Version discipline

Track Ventoy’s own version independently from the ISOs you carry. Updating Ventoy is not the same as refreshing an Ubuntu point release—note both in your change log so rollback stories stay coherent.

  • After upgrade, boot once to the menu only—confirm the reported build string before handing the stick to a user.
  • Keep one “last known good” stick sealed in a drawer; refresh it quarterly.

When things go sideways

If the EFI partition is damaged but the data partition still mounts, specialist disk tools can sometimes rebuild boot structures—back up ISOs first because repair attempts can still go wrong. For irreplaceable files, treat the stick like any other failing drive: clone sector-for-sector before experimenting.

Policy & licensing awareness

Ventoy’s license is separate from the licenses inside your ISOs. Enterprise redistribution of Windows images, OEM recovery media, or classroom software may have contractual constraints—this guide does not replace your legal review.

Future-proofing habits

ARM laptops, hybrid tablets, and mixed UEFI policies will keep evolving. Habits that age well: document firmware quirks per machine model, keep at least one deliberately “boring” USB 2.0 stick for stubborn hosts, and never assume yesterday’s successful boot guarantees tomorrow’s firmware update behaved the same way.

Additional reference (volume II)

Dense notes below extend the first reference block—workflows, edge cases, and vocabulary without repeating the hero install steps.

Windows PE, WIM chains, and driver injection (conceptual)

WinPE-based flows often assume a specific boot loader path and driver load order. When you place a custom WIM on a Ventoy stick, validate that the PE environment includes network and storage drivers for the NIC and disk controller of the machines you service—missing drivers masquerade as “Ventoy broke” when the chain never reaches your script stage.

  • •Keep a driver pack folder on the data partition (not necessarily booted) and document how technicians copy it into PE after boot.
  • •Version WIM filenames with build dates; PE environments age quickly when Windows base images move forward.

Linux ISO families—what changes between them

Debian-derived, Red Hat–family, Arch-based, and immutable desktops differ in live-boot behavior, persistence hooks, and init system. Ventoy lists files uniformly, but the experience inside each ISO is defined by that distro’s maintainers—expect to read their release notes when something “almost boots.”

Rolling vs fixed release

Rolling images update kernel lines frequently—great for hardware enablement, noisy for reproducible classroom labs.

LTS rescue media

Older LTS ISOs trade new drivers for predictability; keep one on the stick when you must match a vendor’s certified stack.

Testing Ventoy images inside virtual machines

VM firmware often defaults to UEFI with a synthetic disk order. Map USB passthrough carefully: some hypervisors expose the stick as a removable disk, others as a SCSI device—both can work, but the guest OS may enumerate controllers differently than bare metal. Treat VM success as necessary but not sufficient before field deployment.

Apple hardware & external boot (high level)

Mac boot policies change across Intel vs Apple Silicon generations. Generic PC multiboot assumptions do not transfer verbatim—verify Apple’s current support matrix for external bootable media before promising a Ventoy-based workflow to creative teams.

First-week checklist for a new Ventoy stick

  1. Write down Ventoy version + partition style immediately after install.
  2. Copy two “known good” ISOs you have already booted elsewhere.
  3. Boot to menu on one UEFI machine and one Legacy machine (if you still maintain any).
  4. Run checksum on every ISO before adding more—establish the habit early.
  5. Label the stick physically with a waterproof tag; digital filenames are invisible in a dark rack.

Incident-style runbook (template)

When a machine fails mid-deployment, capture: firmware version, boot mode string from the Ventoy footer, exact ISO filename, whether Secure Boot was on, and whether any USB hubs sat between stick and port. That bundle answers half of remote triage questions before you ship another stick.

SYMPTOM: ______________________
HOST MODEL / BIOS: _______________
VENTOY LINE (footer): ___________
ISO filename: ___________________
SECURE BOOT (Y/N): _____________
USB PORT (2.0/3.x/direct): _____

Hardware write-protect & kiosk switches

Some enterprise USB drives expose a physical write-lock. If you lock after preparing the stick, you reduce accidental tampering—but you also block Ventoy upgrades until you unlock. Decide per policy: tamper resistance vs agility.

Power states, docks, and Thunderbolt

Laptops on battery power may throttle USB ports; Thunderbolt docks occasionally reorder boot devices. If a stick works direct-attached but fails through a dock, test without the dock before debugging ISO contents.

Filename patterns that scale

Use OS-ARCH-channel-YYYYMMDD.iso style names. Avoid emoji and non-ASCII in filenames if you move sticks across older firmware; Unicode is better supported on modern hosts but still risky in niche industrial PCs.

Keyboard layouts & multilingual installers

Installer language packs are not Ventoy’s layer—set expectations inside each ISO. For international teams, duplicate ISOs with clear language suffixes rather than relying on “it will prompt.”

Rough benchmarking: menu scan time

Time from power-on to menu readiness is dominated by USB speed, file count, and plugin search rules—not CPU branding on the host. When optimizing, reduce file count before buying faster hardware.

Asset tags & inventory

Large shops barcode sticks and map them to owners. Pair a physical sticker with a spreadsheet row: serial (if any), Ventoy version, last verification date, and allowed ISOs for compliance audits.

Air-gapped labs

When networks are forbidden, sneakernet updates are the workflow. Maintain two identical sticks prepared on different days so you can diff them binary-wise if a “silent” corruption is suspected.

Glossary (part 2)

Hybrid ISO
Image that can behave like optical media or disk media depending on how the host reads it.
Casper / persistence
Ubuntu-family live persistence patterns; exact names vary by release.
Dracut
Initramfs tooling common on Fedora/RHEL-line systems.
systemd-boot
Boot manager used in some UEFI-centric Linux setups—not identical to Ventoy’s chain.
GRUB
Bootloader family; you may see GRUB-like screens when troubleshooting.
VHD chain
Booting a Windows environment inside a virtual disk container.
BitLocker
Full-disk encryption on Windows; unrelated to Ventoy’s menu but relevant when imaging disks.
SMART
Disk health data—useful diagnostics alongside boot tests.
DHCP option
Network boot configuration—contrasts with offline USB workflows.

Even more questions

Can I mix personal and work ISOs?

Technically yes; policy-wise maybe not. Separate sticks reduce cross-contamination risk.

Why does my stick feel warm?

Sustained read during long installs heats NAND; ensure airflow in hot environments.

Should I defragment?

Generally irrelevant for flash; focus on filesystem health and free space.

Can I boot from a USB-C–only machine without adapters?

If firmware supports USB-C boot, yes; otherwise carry a certified adapter you have tested.

Why does my menu show duplicate entries?

Hidden copies, sync conflict files, or duplicate filenames in different folders—search the partition with a file manager.

Is exFAT safe for huge ISO libraries?

Often yes for interoperability; still keep backups—single-disk failure is single-disk failure.

Interview-style prompts (study notes)

Question

Explain why a technician might prefer Ventoy over re-flashing between three Linux distros weekly.

Hint: time to switch, reduced wear from full rewrites, fewer human errors picking a target disk.

Question

What would you log when a stick boots on laptop A but not laptop B with the same ISO?

Hint: firmware mode, port type, ISO checksum, Ventoy version.

Narrative scenarios (short)

Scenario A — regional travel

A consultant flies with a single encrypted laptop and an unencrypted Ventoy stick containing only public ISOs. Customs inspection asks to power on; the menu appears harmless. Lesson: content policy matters more than boot tool branding.

Scenario B — campus lab

A lab replaces half its PCs every semester. Technicians clone identical sticks from a master image file stored on a NAS—Ventoy version pinned, ISOs hashed weekly. Drift is caught when checksums differ, not when users complain.

Scenario C — home user

A hobbyist keeps Windows installer, two Linux lives, and a rescue disk. They rarely update Ventoy itself—acceptable until a firmware change forces Secure Boot enrollment; then they revisit the installer once a year.

Closing principles

  • Verify before you trust—checksums beat assumptions.
  • Document while fresh—memory fades faster than disks.
  • Separate roles—work vs personal sticks reduce risk.