If you’re ever seen Neofetch, you’re likely to want something like it for Windows. It’s a command-line tool that displays a quick system snapshot. It shows OS version, CPU, GPU, RAM, uptime, shell, storage and more, alongside a rendering of the OS logo as “ASCII art.” But Neofetch is mostly a Linux/Unix thing that requires a Bash shell to run. It was also archived in April 24. It still works, but there are better choices for Windows. For those seeking Windows Neofetch alternatives, the best options are fastfetch and winfetch.

Windows Neofetch Alternatives Are Helpful, or Necessary

Again: Neofetch is a Bash script. That explains most of the friction inherent in running Neofetch on Windows. That is, it requires Git Bash or WSL — neither of which is a native Windows tool. The script itself froze at v7.1.0 when the repository was archived. Worse, going forward Neofetch is dead in the water: no updates, no bug fixes, no future-forward functionality.

Think about what Neofetch actually does: it reads your OS version, CPU, RAM, and a handful of other system facts, then prints them alongside an ASCII logo. Running an outdated Bash script through a compatibility layer to accomplish that feels like overkill. Native tools handle this job more cleanly, more quickly, and without the extra dependencies.

2 Strong Alternatives: Fastfetch and Winfetch

Both of these facilities are actively maintained, and update regularly. Either one can take over for Neofetch without skipping a beat.

Fastfetch

Fastfetch is written in C and installs as a native binary. Speed is its calling card — it fetches and renders system info noticeably faster than Neofetch ever did. Cross-platform support (Windows, Linux, macOS) makes it useful across mixed environments. Install it with any of the major Windows package managers:

winget install fastfetch

Once installed, launch it by typing fastfetch at any prompt. Configuration lives in a JSONC file, so customization is straightforward and version-control friendly. Here’s what it looks like on my AMD-based Flo6 desktop (click image to enlarge):

Winfetch

Winfetch is a pure PowerShell script — Windows-only, and deliberately so. It installs directly from the PowerShell Gallery:

Install-Script winfetch -Scope CurrentUser

For anyone already running Windows Terminal with an Oh My Posh prompt and Nerd Fonts, winfetch slots right in. The output renders cleanly alongside a styled prompt, and the whole setup feels native rather than bolted on. You can see it in the lead-in screencap.

The Winfetch Path Gotcha

What the lead-in graphic shows is me getting past the requirement that the winfetch script must be somewhere in $PATH to work. In fact, after I installed it, I got this error when I tried to run it:

This happens because the installer drops the script into a specific, pre-assigned folder:
C:\Users\Documents\Powershell\Scripts\
Powershell does not, however, automatically add that folder to the $PATH environment variable. So even though the script is installed, it doesn’t run from the command line. Easily fixed, however, as also shown in the lead-in graphic, through a series of simple steps.

Fixing Winfetch, Step-by-Step

Step 1: Confirm the install location

Run this to verify exactly where the script landed:

Get-InstalledScript winfetch | Select-Object Name, InstalledLocation

Step 2: Run it directly as a workaround

Before touching PATH, you can invoke winfetch immediately using its full location:

& "$((Get-InstalledScript winfetch).InstalledLocation)\winfetch.ps1"

That works, but typing it every time is obviously impractical. The permanent fix takes about ten seconds.

Step 3: Add the Scripts folder to PATH permanently

Open PowerShell and run the following command to append the Scripts folder to your PATH inside your profile:

Add-Content $PROFILE "`n`$env:PATH += `";`$([System.Environment]::GetFolderPath('MyDocuments'))\PowerShell\Scripts`""

Then reload your profile in the current session:

. $PROFILE

After that, typing winfetch works cleanly from any new PowerShell session. No more “not recognized” errors, no manual path juggling.

Which to Use: Winfetch or Fastfetch?

The choice comes down to how you work, not which tool is objectively better.

Reach for fastfetch when you want something fast, dependency-free, and portable across platforms. Winfetch makes more sense if you live inside PowerShell and want the output to feel like it belongs there — especially alongside Windows Terminal and a styled prompt. Both tools beat neofetch on Windows in 2026. Pick one and move on. Either way, you get a clean, colorful system info display — and you leave a frozen Bash script behind where it belongs. That’s about as good as tradeoffs get here in Windows-World. Cheers!

Following the Oh My Posh documentation, I recently ran oh-my-posh font list on my ASUS Zenbook A14 . It’s a Qualcomm Snapdragon X Elite ARM64 machine running Windows 11. The result? Nothing. No output, no error, no interactive list, just a blinking cursor that eventually handed the prompt back to me. That same command works beautifully on all my x64 PCs and laptops. Thus, Oh My Posh  shows real ARM vs x64 differences. Indeed, this sent me down a rabbit hole to figure out what OMP’s font subsystem does under the hood.

How Oh My Posh Shows Real ARM vs x64 Differences

When you run oh-my-posh font list on a working x64 machine, you get a list of available Nerd Fonts pulled live from GitHub. You can scroll that list, select a font, and it copies the name into the paste buffer for subsequent re-use. It’s helpful.

On my ARM64 Zenbook, none of that renders. The command exits silently. No crash, no error code, no partial output. That silence is itself a clue.

Inside the Oh-My-Posh Font Subsystem

OMP is written entirely in Go, and its font subsystem layers several platform-specific APIs and third-party frameworks. Understanding what those are and how they work explains why ARM64 falls short.

The first dependency is Bubble Tea a terminal oriented display and interaction UI. OMP’s font commands use Bubble Tea’s program model to launch, render, and manage the font list. Bubble Tea drives the terminal via ANSI/VT escape sequences and calls into Go’s golang.org/x/term package to manipulate terminal raw mode. On x64 Windows, Windows Terminal’s VT rendering pipeline handles these sequences without issue. On ARM64, subtle gaps in how the ARM64 console host processes certain VT sequences — particularly around alternate screen buffers and raw-mode toggling — can cause Bubble Tea’s rendering loop to fail before it draws a single line.

The second dependency is a live HTTPS call to the Nerd Fonts GitHub Releases API, which is how OMP fetches the current font list. This call goes out over Go’s standard net/http TLS stack. On ARM64, Go’s TLS implementation compiles natively, but the ARM64 binary links against a slightly different set of system crypto libraries. If that HTTP call fails silently, owing to a timeout, a TLS handshake hiccup, or a missing response, Bubble Tea never receives the data it needs to populate the list, and the program exits with nothing to show.

The third set of dependencies covers font installation: GDI32’s AddFontResourceW function (called via Go’s syscall and unsafe packages), Windows Registry writes through golang.org/x/sys/windows/registry, and a PostMessageW broadcast carrying WM_FONTCHANGE to notify the shell that new fonts are registered. These are the plumbing that oh-my-posh font install uses after the list is displayed. They are less relevant to the silent-exit problem, but they represent additional surfaces where ARM64’s native API behavior diverges from x64.

Where ARM Falls Down (or Out)

The core issue is that OMP’s font tooling was developed and battle-tested on x64 Windows. The Bubble Tea TUI path, the live GitHub fetch, and the GDI32 font registration flow all work reliably there. ARM64 Windows is a native platform now — not emulation — but the console host, terminal rendering, and system library behavior still carry edge cases that x64 does not.

Bubble Tea’s dependency on terminal raw mode and VT escape handling is especially fragile on ARM64 because Windows Terminal’s ARM64 build has historically lagged behind x64 in VT conformance. A Bubble Tea program that initializes correctly on x64 can silently short-circuit on ARM64 if golang.org/x/term‘s raw-mode call returns an unexpected result, causing the event loop to spin zero times and exit.

The irony is that OMP itself — the prompt rendering engine — works great on ARM64. The font management tooling sits on a different, more complex stack, and that stack exposes the seam between x64-matured tooling and an ARM64 Windows environment that is still catching up.

Takeaways for ARM Users

If you hit silent output from oh-my-posh font list on an ARM64 Windows machine, you now know it is not user error. It’s a real platform gap rooted in Bubble Tea TUI compatibility, live HTTP fetching, and ARM64 console API edge cases. The workaround for the moment is to install Nerd Fonts the old-fashioned way: grab the zip directly from the Nerd Fonts GitHub releases page and drop the TTF files into your user fonts folder manually. It’s not as elegant as OMP’s interactive installer, but it gets the job done.

This kind of difference is exactly why I find ARM Windows fascinating. The platform is capable, but it still surfaces small, instructive wrinkles like this one. Though I’ve seen nothing to make me question my investment in ARM hardware, oh-my-posh font list returning nothing is about as vivid a demonstration as I have seen of possible impacts of platform differences. That’s a thing worth watching out for, here in Windows-World.

Note: Only newer OMP versions (30.X.X) and higher support the font list capability. If you’re run the bog standard version on x64 (v29.0.2) you won’t see it, either. Winget should get the latest version (30.6.5) into its pipeline soon, after which you can see it, too. On the right kind of PC, anyway…

I just ran PC Manager’s Deep Cleanup on my Flo6 desktop. As usual, it cleaned a lot of what it found: 11.4 of 14.6 GB wound up gone. Also, as usual it shows around 3GB remaining for my three browsers — namely, Firefox, Chrome and Edge. So I asked Copilot: why do these programs show up in their numbers? It opines (and I concur) that PC Manager Browser space is mostly volatile. Indeed the figure is kind of illusory. It’s worth understanding before treating browser cache cleanup as a valid way to recover disk space.

Take a look at the final results from my Deep Cleanup just now from the lead-in screencap. Notice that it shows 1 GB for Firefox, 1.6 GB for Chrome and ~277 MB for Edge. Keep those numbers in mind.

Why Say: PC Manager Browser Space Is Mostly Volatile?

Here’s the core issue: browser cache is engineered to be ephemeral. It’s written, read, and purged in a continuous cycle governed by cache-expiry headers, per-origin storage quotas, and the browser’s own self-management routines. The moment you fire up your browser after a cleanup and start clicking around, the cache begins refilling. Within 30 to 60 minutes of ordinary browsing, most browsers will have rebuilt several hundred megabytes of cached content — sometimes more, depending on how media-heavy the sites you visit are.

Chrome and Edge both enforce internal storage quotas and will self-evict stale or low-priority cache entries automatically when those quotas are approached. In other words, the browser is already managing this space on your behalf, without you lifting a finger. Firefox operates similarly under its own quota management framework.

In short: you didn’t “save” 2 GB when you cleared browser cache. You borrowed 2 GB temporarily — until your next browsing session rebuilt most of it. Sort of like the storage equivalent of pushing water uphill.

Check out these numbers: they represent the memory footprint for my three browsers.

Note that those numbers fall near the potential savings that PC Manager reports for each one. That’s no coincidence, it simply represents reclaiming space that the browsers will suck back up as soon as you turn them back on, and open some tabs.

What Real, Valid Savings Look Like

Contrast browser cache with the categories that represent genuinely permanent space recovery. Windows Update cleanup files — the old installer packages and superseded component stores left behind after updates — can run anywhere from 500 MB to 2 GB, and once deleted, they do not return. Windows Error Reporting logs are similarly non-regenerating under normal conditions. The Recycle Bin is obvious. Orphaned app data left behind by software you’ve already uninstalled is another solid target. Thumbnail cache does rebuild, but far more slowly than browser cache, so it offers a more durable short-term gain.

A typical monthly cleanup on a moderately used Windows 10 or 11 machine might yield up to a 5 GB of truly permanent, non-regenerating space. That’s a lot less dramatic than the headline figure PC Manager flashes at you — but it’s real. And it stays real.

Do You Need to Clean Browser Cache?

Maybe, but go into that effort with adjusted expectations. Clearing browser cache could deliver a brief responsiveness improvement. Thus, if the cache has grown bloated with stale or corrupt entries, or to make room in storage-intense scenarios, such as recording a long screen capture session, installing a large application, or freeing up breathing room on a drive that’s genuinely running tight. Otherwise, don’t expect much either in the short or long term.

If you’re truly short on disk space, PC Manager’s Large Files finder and the Windows Update Files cleanup row are far more useful targets. The browser cache, left alone, will look after itself. That’s the point!

Here in Windows-World keeping things clean does have its reward. But some things are more worth cleaning up than others. Browser cache is near the end of that list, and best left alone.