Now that the adrenaline rush from getting icons working in WinTerm has subsided, I’ve started looking more closely at which items actually display icons in response to winget list –details. My conclusion from this analysis? Some have icons, others don’t. Indeed, the number of qualifying items is less than I originally thought: exactly 37 of the 143 total packages that winget manages show me something pretty to look at. ‘Sup with that? Here’s my take…

Which Some Have Icons, Others Don’t?

The test machine is a Lenovo ThinkPad X12 Gen 1 Hybrid running Windows 11 — a clean-ish install with the usual factory bloatware and a handful of my own tools layered on top. Running winget list --details produces 143 packages. Of those, exactly 37 display colorful, sixel-rendered icons in the terminal output. The remaining 106 show nothing. No icon, nor placeholder. No ghostly outline. Just… text.

What’s striking is how that output is organized. All 37 icon-bearing packages appear first in the output stream, clustered together like a parade of floats. Then there’s a visual cliff — you scroll past the last colorful logo and drop straight into a desert of monospaced text. It’s like walking from a gallery opening into a DMV waiting room. Same terminal. Same command. Two completely different experiences.

Twenty-six percent. That’s the icon coverage rate. On a machine with 143 packages, barely a quarter of them get the visual treatment. The other 74%? It’s still 1985 out there.

The Installer Category Absolutely Rules

Here’s where things get interesting — and by “interesting” I mean “so clean it almost feels like a prank.” I started looking for the variable that separates the haves from the have-nots. Publisher? Nope — Microsoft shows up on both sides. Source repository? Irrelevant. Architecture? x64 and x86 packages appear in both camps. Update date? No correlation. Then I looked at the Installer Category field, and the mystery evaporated.

The Pattern

Every single package with an icon has Installer Category exe or msi. These are traditional Win32 desktop applications installed via ARP (Add/Remove Programs) entries. Every single package without an icon has Installer Category msix — modern packaged apps from the Microsoft Store or sideloaded MSIX bundles.

There’s a 100% correlation. Not 98%. Not “mostly.” One hundred percent. Win32 equals icons. MSIX equals no icons. The dividing line isn’t publisher, isn’t source, isn’t architecture, isn’t age. It’s installer category, and nothing else.

What Does This Mean?

Why does this make sense architecturally? Because the two package types get their metadata from fundamentally different places:

• Win32 packages (exe/msi) live in the winget community repository, where their manifest files include IconUrl fields pointing to PNG images. Winget fetches those URLs, converts the images to sixel format, and Terminal renders them inline. Clean pipeline. Works beautifully.
• MSIX packages get their metadata from the Microsoft Store catalog or from the AppxManifest.xml embedded inside the package itself. Neither of these sources exposes icon URLs in a format that winget’s sixel rendering pipeline can consume. The icons exist — the Store shows them, Dev Home shows them, the Start Menu shows them — but terminal-facing winget can’t reach them through the MSIX metadata path.

Searing Irony: MS Apps Are Holdouts

And here’s where the comedy writes itself. Of the 106 iconless MSIX packages on this PC, 96 are published by Microsoft. Let that sink in. The company that built winget. The same outfit that built Windows Terminal. The company that built the sixel rendering pipeline. The developers who invented the MSIX packaging format… can’t show its own icons in its own tool.

We’re not talking about obscure infrastructure components here. The missing-icon list reads like a “Best of Microsoft” compilation album:

• Flagship apps: Microsoft Edge, Microsoft Teams, OneDrive, Outlook, Paint, Photos, Calculator, Camera, Notepad
• Windows itself: Windows Terminal, Microsoft Store, Windows Security, Snipping Tool, Windows Media Player
• Productivity & lifestyle: To Do, Sticky Notes, Phone Link, Quick Assist, Clipchamp, Power Automate
• Entertainment & social: Xbox, Solitaire, Dev Home

Then there are the framework and runtime packages — the plumbing that nobody sees but everything depends on. .NET Native Frameworks (versions 1.3, 2.1, 2.2), VCLibs (2012, 2013, 2015), UI.Xaml (2.7, 2.8), WindowsAppRuntime (1.6, 1.7, 1.8) — many appearing twice, once for x64 and once for x86. These make up vital Windows infrastructure. You wouldn’t expect icons on a Visual C++ redistributable. But Teams? Edge? Photos? These are flagship consumer applications with instantly recognizable logos. And in the terminal, they’re anonymous.

What Else Is Missing?

The remaining ~10 non-Microsoft MSIX packages without icons are third-party apps that happen to ship as MSIX bundles, mostly OEM-related: Intel Graphics Software, Thunderbolt Control Center, Dolby Audio Premium, Lenovo Vantage, Notepad++ (there’s also an installable version, with icon showing), Realtek Audio Control, Synaptics TrackPoint and TouchPad drivers, and — somewhat poetically — Oh My Posh, a tool whose entire reason for existing is making terminals look prettier.

Why DOES MSIX Fall Behind?

To understand the gap, you have to understand the pipeline. Winget’s icon rendering isn’t magic — it’s a four-step relay race, and MSIX packages drop the baton at the starting line.

Here’s how it works for Win32 packages:

1. Manifest lookup. Winget looks up the package in its community repository and finds the package manifest YAML file.
2. Icon URL extraction. The manifest includes an IconUrl field pointing to a hosted PNG or SVG image.
3. Sixel conversion. Winget fetches the image from the URL and converts it to sixel format — an inline graphics encoding standard that dates back to DEC terminals in the 1980s, now reborn in modern terminals.
4. Terminal rendering. Windows Terminal, with enableSixels: true in its experimental settings, interprets the sixel data and renders the icon inline, right next to the package name.

For MSIX and Store packages, this pipeline breaks at steps 1 and 2. MSIX packages registered through the Store don’t necessarily have community manifests with IconUrl fields. Their metadata comes from the Store catalog API or from the AppxManifest.xml bundled inside the package. Neither of these sources feeds into winget’s sixel rendering path.

It’s not that MSIX packages don’t have icons — they absolutely do. The Microsoft Store displays them beautifully. Dev Home displays them. The Start Menu displays them. Your taskbar displays them. But the specific pipeline that converts an icon reference into sixel terminal output hasn’t been connected to the MSIX metadata source. The icons are there. The rendering engine is there. The wiring between them? Not yet.

What Comes Next? “Under Construction…”

The good news — and it’s genuinely good news — is that this is just an implementation gap, not a fundamental limitation. Every piece of the puzzle belongs to MS:

• Winget — Microsoft’s package manager
• Windows Terminal — Microsoft’s terminal application
• Sixel rendering — implemented by the Terminal team
• MSIX — Microsoft’s modern packaging format
• The Store catalog API — Microsoft’s metadata service

There are no third-party dependencies to negotiate. No standards bodies to petition. No licensing hurdles to clear. Connecting the MSIX metadata path — where the icons already live — to the sixel rendering pipeline is a plumbing job. An important one, but a plumbing job nonetheless.

When (not if) Microsoft bridges this gap, the icon coverage on a typical Windows machine should jump dramatically. We’re talking from 26% to potentially 90% or higher, essentially overnight. On this ThinkPad, that would mean going from 37 icons to 130+. The visual cliff in the winget list output would disappear, replaced by a continuous stream of colorful, identifiable package icons.

The winget-cli GitHub repository is the place to watch. Feature requests and pull requests related to MSIX icon rendering or Store catalog icon integration would be the signal that the coverage expansion is inbound. Given that Microsoft went to the trouble of implementing sixel rendering in the first place — a non-trivial engineering effort — it seems unlikely they’d leave 74% of packages iconless.

One in Four Is a Good Start…

So here we are. The sixel icon feature in Windows Terminal works. It works beautifully, in fact — those 37 Win32 packages look fantastic, their colorful logos rendered crisply inline, transforming a wall of text into something you can actually scan visually. The three-step setup is straightforward. The technology is sound.

It’s just that only 37 apps showed up to the party in full regalia, while 96 of Microsoft’s own applications stand in the corner without name tags. Edge — the browser Microsoft preinstalls on every Windows PC on Earth — doesn’t get an icon. Teams — the collaboration hub Microsoft spent billions promoting — doesn’t get an icon. Windows Terminal itself, the application rendering the icons, doesn’t get an icon. You have to admire the irony, even if you wish you didn’t.

The feature is real. The gap is clear. The fix is feasible. And in the meantime, those 37 Win32 apps with their lovingly rendered sixel icons are living proof that the future of terminal-based package management looks a lot more colorful. Now, somebody needs to connect the rest of the plumbing.

In Windows-World, 26% is a start. A visually delightful, architecturally illuminating, slightly ironic start. But MS can do better. Hopefully, sooner rather than later. Let’s see!