NTDEV’s tiny11 project spawned a new contender: Nano11 — a community-made script that strips Windows 11 to the bone and, in one recent demonstration, produced an ISO file reported at just 2.28 GB and an installed system that was reduced to roughly 3.25 GB after aggressive compression and pagefile removal. The result is headline-grabbing: a fully bootable Windows 11 image that can be carved down to a fraction of the usual 20–30 GB on-disk footprint — but it arrives with severe caveats. HotHardware’s hands-on report summarizing NTDEV’s demo captures the numbers and the workflow that produced them. (hothardware.com)
Windows 11 in its stock form is a modern desktop OS whose on-disk size commonly ranges from roughly 20 GB to 30+ GB after a clean install. Project maintainers in the Windows customization community — notably NTDEV (the author behind Tiny11) and a growing set of offshoots — have systematically removed visual features, services and bundled apps to produce slim images useful for VMs, testing, or squeezing Windows onto very small storage targets. These efforts combine two main levers:
But for anyone requiring a secure, maintainable, and user-ready Windows experience, these builds are a poor fit. The space savings come primarily at the cost of updateability, maintainability, and compatibility. HotHardware and other observers emphasize that Nano11 is “extreme” and meant for experimental and testing contexts, not production use. (hothardware.com)
If the headline — “Windows 11 install down to 2.28 GB” — grabbed attention, the sensible takeaway is this: the number is technically plausible, demonstrably reproducible under tightly defined conditions, and useful in limited contexts. But the operational trade-offs are severe enough that anyone tempted to adopt Nano11 in daily use should pause, test extensively in VMs, and prefer more conservative slim-builds or rely on CompactOS on top of a full, serviceable Windows installation when security and updates matter.
Nano11 and the broader tiny-OS movement raise useful questions for Microsoft and the wider PC ecosystem: why do modern OSes ship with so many duplicative components by default, and how can manufacturers and users get a smaller, secure Windows without sacrificing serviceability? For now, the answer for most users remains: stay with supported builds unless you have clear, narrow requirements and the technical expertise to manage the risks. (hothardware.com)
Source: HotHardware Forget Tiny11, This Nano11 Script Shrinks Windows 11 Install To Just 2.28 GB
Background / Overview
Windows 11 in its stock form is a modern desktop OS whose on-disk size commonly ranges from roughly 20 GB to 30+ GB after a clean install. Project maintainers in the Windows customization community — notably NTDEV (the author behind Tiny11) and a growing set of offshoots — have systematically removed visual features, services and bundled apps to produce slim images useful for VMs, testing, or squeezing Windows onto very small storage targets. These efforts combine two main levers:- surgical removal of components (Edge, Defender, Windows Update components, many drivers, Windows Component Store elements), and
- aggressive on-disk compression techniques (CompactOS / LZX and targeted NTFS compression via the compact.exe tools). (tomshardware.com)
What Nano11 (and similar projects) actually does
The high-level method
Nano11’s approach — as summarized by the HotHardware write-up and mirrored by other community tools — is a two-stage shrink:- First, remove or disable a large set of system components that Windows normally ships with: Windows Defender, Windows Update/servicing, Edge, recovery components, many device drivers, and large parts of WinSxS (the Windows Component Store). This directly reduces the number of files and total bytes in the install payload. (hothardware.com)
- Second, compress the installed files using Windows’ native compression utilities: CompactOS and the compact.exe /EXE:LZX options, which store many system files in highly compressed form and decompressed on-the-fly as needed. Deleting large runtime artifacts such as the pagefile and trimming other system data then yields further space savings. Microsoft’s compact command exposes LZX as the most compact algorithm and the /CompactOs switch to compress system binaries. (learn.microsoft.com)
The specific numbers reported in the HotHardware demo
According to HotHardware’s write-up of NTDEV’s demo:- The built ISO shrank to 2.28 GB.
- A standard installation initially registered 8.32 GB used on disk.
- After running Windows’ compact/compression across the drive, removing the pagefile, and other trimming, the live system’s used space was reported as 3.25 GB. (hothardware.com)
Why the numbers are both believable — and reason to be cautious
Why the compression claims are technically feasible
- Microsoft’s tools expose very powerful compression: the built-in compact.exe supports LZX compression — explicitly documented by Microsoft as the most compact NTFS compression algorithm available — and CompactOS can compress OS binaries. When applied en masse to a freshly installed system, these tools can produce dramatic reductions because modern OS images contain large duplicated libraries, driver packages, and dormant components that compress very well. The Microsoft documentation confirms the compact.exe syntax and the availability of LZX. (learn.microsoft.com)
- The Tiny11 ecosystem (NTDEV’s work) has shown repeatedly that stripping plus compression can cut Windows to single-digit gigabyte installs or even smaller in extreme experimental builds. Tom’s Hardware and other outlets have documented Tiny11 Core variants with ~2 GB ISOs and ~3–4 GB installed footprints after similar treatment. That makes NTDEV’s 2.28 GB ISO and the compressed 3.25 GB installed system plausible in context. (tomshardware.com)
Why the numbers can be misleading or non-representative
- The headline figures usually refer to a particular build, compression step, and post-install housekeeping (e.g., removing pagefile, moving or deleting recovery partitions). They do not reflect a general-purpose Windows 11 suitable for day-to-day use on a production machine. HotHardware itself emphasizes that Nano11 is “extreme experimental” and not serviceable; installing updates or adding drivers can break these images. (hothardware.com)
- Compression savings depend heavily on the data layout and whether the compressed image remains practical: compressing executables and system DLLs with LZX reduces on-disk usage but increases CPU cycles for decompression at runtime. On modern desktop hardware that cost is often acceptable; on very old or low-power hardware the trade-off can impact performance. (wimlib.net)
- Removing the Windows Component Store and update-related services generally prevents the usual Windows update flow from working. That means security updates and cumulative patches cannot be applied reliably, which is a significant operational risk. Multiple write-ups on Tiny11/Tiny11 Core warn that “no serviceability” and broken update mechanisms are a byproduct of these extreme trims. (tomshardware.com)
What Nano11 removes — and what that means in practice
- Windows Update & Recovery components: Without them, you won’t receive cumulative security updates in the normal fashion; attempting to add updates later may fail or restore removed components. This is a fundamental trade-off: saving space forgoing updateability. (hothardware.com)
- Windows Defender / security services: Many lightweight builds remove Defender to save space. That means running a vulnerable OS unless alternative security controls are installed and kept up-to-date. For machines that will see untrusted content, this is a non-trivial risk. (neowin.net)
- Device drivers: Nano11 reportedly removes nearly all built-in device drivers. You risk loss of out-of-the-box hardware compatibility, requiring manual driver installs — often impossible if updates and package servicing are disabled. (hothardware.com)
- WinSxS and servicing store elements: These store multiple component versions for servicing and updates; trimming them saves space but breaks the component servicing model. That can cause unexpected failures and make future servicing impractical. (tomshardware.com)
- Applications and UI components: Edge, the Store, telemetry and several GUI subsystems are often removed. For many users this is acceptable; for others (who need Microsoft Store apps, Copilot integration, or browser features) it’s a show-stopper. (tomshardware.com)
The risks — security, reliability, and licensing
- Security risk: Stripping Defender and update channels leaves the system exposed unless compensated by other measures (third-party AV, locked network environments, VM isolation). Community projects often explicitly recommend these builds only for test/dev or ephemeral VM images. (tomshardware.com)
- No serviceability / update breakage: Significant removals typically result in a system that cannot accept official cumulative updates; attempting to do so may restore removed components or brick the install. For devices with important data or that must remain secure, that’s a hard blocker. (tomshardware.com)
- Compatibility pitfalls: Removing drivers and services can break applications, games, audio, networking, or printing. Expect to spend time troubleshooting missing features. (hothardware.com)
- Legal/licensing and supply-chain concerns: The original Windows binary remains Microsoft IP. Community-created builds that redistribute modified ISOs raise both licensing and integrity questions. Using unofficial ISOs sourced from third parties (not the original Microsoft download plus a local builder script) compounds supply-chain risk. Many reputable guides insist: download your base ISO from Microsoft and apply local build steps, rather than relying on pre-built community ISOs. (github.com)
How the Nano11 workflow typically looks (high-level steps)
- Download an official Windows 11 ISO from Microsoft (recommended).
- Mount the ISO and extract or reference its sources\install.wim (or install.esd).
- Run the Nano11 builder script (or a similar builder), which automates removals and produces a trimmed install.wim. The script will prompt for the mounted drive letter and the desired SKU. (github.com)
- Build a new ISO (oscdimg or similar) containing the trimmed image.
- Install the trimmed image to target hardware or VM.
- After installation, optionally run Windows’ compact.exe across the system to apply LZX compression and delete pagefile/hiberfil as desired (this requires care). Microsoft’s compact.exe documentation shows the /EXE:LZX option and /CompactOs switches that enable these behaviors. (learn.microsoft.com)
Alternatives and where Nano11 fits in the ecosystem
- Tiny11 / Tiny11 Core (NTDEV) — A mature community project that balances usability and size more conservatively than extreme builds. Tiny11 has multiple flavors (full, core, experimental). Tiny11 Core demonstrated ~2 GB ISOs and ~3.3 GB installed sizes in documented tests. These projects are well-known and frequently discussed by the Windows customization community. (tomshardware.com)
- AtlasOS / Refined third-party builds — Other community projects take different trade-offs; some prioritize gaming performance or latency reductions rather than minimal size.
- Use cases where Nano11-style images make sense:
- ephemeral test VMs and CI runners where disk footprint matters more than serviceability;
- embedded or constrained environments where a bespoke and quarantined OS is acceptable;
- forensic or research labs that need minimal runtime images and control updates externally.
- When you should not use it:
- production desktops or laptops holding valuable data;
- systems that must remain patched, compliant, or used by non-technical users.
Best practices and recommendations for curious users
- Always start from an official Microsoft ISO. That reduces supply-chain risk and makes it possible to rebuild locally. (github.com)
- Use virtual machines first. Run the trimmed image inside a VM for days or weeks to surface compatibility issues before touching physical hardware. Nano11-style images are perfect for VM-based testing. (hothardware.com)
- Keep a clean reference install and backups. If a trimmed image breaks, a restore from a known-good image will save hours. Use full disk images (Macrium, Clonezilla).
- Consider alternative mitigations to save space without destroying updateability: install full Windows and then selectively use compact.exe or remove only non-essential apps. CompactOS and /EXE:LZX alone can save many gigabytes while leaving servicing intact in many scenarios. Microsoft docs show these options. (learn.microsoft.com)
- If you need security, do not remove Defender or the update mechanism. Instead, focus on removing optional app bundles and user-facing bloat. That preserves patchability.
How to verify claims like “2.28 GB” if you’re doing this yourself
- Reproduce the exact workflow: same base ISO (SKU and build number matters), same script version, same compression flags. Small differences in which files are removed or which compression mode was applied can change final numbers dramatically.
- Log intermediate sizes: measure install.wim size, ISO size, and after-install used disk space (before and after compact.exe runs). That way you can isolate where the biggest savings come from.
- Beware of ephemeral properties: removing pagefile or hiberfil.sys temporarily reduces reported used space but at the cost of system stability/functionality on low-RAM systems.
- Check community issue trackers and repo notes: builder scripts often include explicit “this only works on build X” warnings and known issue lists. The Nano11 builder forks and repositories document supported build numbers and language/SKU caveats. (github.com)
Final assessment — who should care and why
Nano11 and similar tiny OS builders are remarkable engineering demonstrations that reveal how much redundancy and optional baggage modern operating systems carry. For enthusiasts, testers, and virtualization-heavy environments they can provide enormous practical value: faster deploy times, smaller storage budgets, and bespoke test images.But for anyone requiring a secure, maintainable, and user-ready Windows experience, these builds are a poor fit. The space savings come primarily at the cost of updateability, maintainability, and compatibility. HotHardware and other observers emphasize that Nano11 is “extreme” and meant for experimental and testing contexts, not production use. (hothardware.com)
If the headline — “Windows 11 install down to 2.28 GB” — grabbed attention, the sensible takeaway is this: the number is technically plausible, demonstrably reproducible under tightly defined conditions, and useful in limited contexts. But the operational trade-offs are severe enough that anyone tempted to adopt Nano11 in daily use should pause, test extensively in VMs, and prefer more conservative slim-builds or rely on CompactOS on top of a full, serviceable Windows installation when security and updates matter.
Nano11 and the broader tiny-OS movement raise useful questions for Microsoft and the wider PC ecosystem: why do modern OSes ship with so many duplicative components by default, and how can manufacturers and users get a smaller, secure Windows without sacrificing serviceability? For now, the answer for most users remains: stay with supported builds unless you have clear, narrow requirements and the technical expertise to manage the risks. (hothardware.com)
Source: HotHardware Forget Tiny11, This Nano11 Script Shrinks Windows 11 Install To Just 2.28 GB