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…