Glint

A file explorer for Windows that opens folders in milliseconds, shows the size of every folder, and finds any file on any drive in an instant.

Built in Rust on fd, pdu and ripgrep, with an NTFS index like Everything's.

Download the installer · Website · Benchmarks · Features · Shortcuts · Build from source

Why

• Folders open in milliseconds. System32's 5,092 items are on screen 12 ms after you press Enter, and a folder of 100,000 files takes 114 ms. One Win32 pass reads names, sizes, dates and attributes together, Rust sorts them, and the list draws only the rows you can see.
• Every folder shows its size. File Explorer keeps them out of the list. Here they're in the Size column as the folder opens (all of C:\Windows sized in 0.4 ms from the index), or one click away with pdu. Sort by size, or open Disk usage for a treemap like WizTree's, and you see what's filling your disk.
• Any file on any drive, in milliseconds. Turn on instant search and a small service reads each NTFS drive's Master File Table once, the way Everything does, then follows the change journal. Every kernel32.dll on three drives (over 3 million names) is listed in about 8 ms. Without it, fd streams results as it finds them.
• ripgrep for what's inside files: regular expressions, whole words, replace across files, and a syntax-highlighted preview.
• Thumbnails that never hold up the folder. Switch to the grid (Ctrl+Shift+2) and a folder of 1,200 photos is still on screen in 9.3 ms, with the thumbnails filling in right after from Windows' own thumbnail cache (30 in 71 ms). Photos Windows hasn't seen yet are made on several threads at once, about 220 a second, where Windows' isolated thumbnail process manages about 50.
• Archives open like folders. Zip, 7z, RAR, cabinet and tar archives (.tar.gz and the other compressed tars too), single .gz, .xz, .bz2, .zst or .lz4 files, and with Open as archive, .docx, .jar and .msi files: press Enter on one and browse it in the list or the grid, with folder sizes, previews and thumbnails: a zip of 50,000 files is on screen 57 ms after Enter, and nothing is extracted until something needs a file's bytes. Copy, Copy to other pane and drag out extract through Windows' file engine.
• The tools File Explorer leaves out. Find duplicate files by their content and recycle, hard-link or (on ReFS and Dev Drives) clone the extra copies, clear out the build output and package caches of projects you've left alone, see which program is holding a file open (and close it), list what changed in a folder lately, check a download against its published SHA-256, and rename many files at once with a live preview and Undo.
• Space to Quick Look, Ctrl+K for everything else. See any file full size without opening it, Word, Excel and PowerPoint documents included (through Windows' own previewers, as in File Explorer), and arrow through the folder. Jump to the folders you use most (ranked by frecency, like zoxide) or run any command by typing a few letters.

Benchmarks

Task	Where	Found	Time
Open a folder	C:\Windows	108 items	6.3 ms
	C:\Windows\System32	5,092 items	12 ms
	C:\Windows\WinSxS	21,650 items	73 ms
	a test folder	100,000 files	114 ms
Size every folder ¹	C:\Windows	56 GB	0.4 ms
Map disk usage ¹	all of C:\, six levels down	20,000 biggest of 464 GB	53 ms
Find files by name ¹	kernel32.dll on all three drives	18 files	7.7 ms
	*.dll in System32 and its subfolders	5,015 files	36 ms
Search inside files	DriverVer in C:\Windows\INF (81 MB)	1,313 matches in 838 files	39 ms
Open a folder in the grid	1,200 photos	1,200 items	9.3 ms
Show its thumbnails ²	from Windows' thumbnail cache	the 30 on screen	71 ms
	photos Windows hasn't seen yet	the 30 on screen	242 ms
	C:\Windows\Web\touchkeyboard

Each time runs from pressing Enter until everything is on screen, as the app's status bar reports it: the median of 5 runs, with the files already in Windows' cache (as when you browse back and forth). Intel Core Ultra 7 265K, NVMe SSD, Windows 11, release build. The status bar shows the time for every folder and search, so you can check these numbers on your own machine.

¹ With instant search on. Without it, fd and pdu do the work: fd on its own lists the same 5,015 DLLs in 0.1–0.3 s, and takes 8 s for a name search across a 219 GB home folder.

² From the first thumbnail asked for to the last one in, as the status bar reports it (30 thumbnails in 71 ms), each run a fresh start of the app, so none came from its own memory. Asked for all at once, 1,200 photos come 1,100 a second from Windows' cache, and are made at 220 a second when Windows hasn't seen them.

³ Its list of entries read (47 ms of that), nothing extracted; each run a fresh start of the app, so Glint didn't have the archive in memory yet. After that, every folder in it is read from memory in 0.2 ms. See docs/archives.md.

Features

Files

• Instant folders. Each folder is read in one Win32 enumeration pass and sorted in Rust in natural order (img9 before img10), then drawn as a virtual list. The status bar says how long it took: read in 0.3 ms · shown in 6.3 ms.
• Find files by name. Typing in the search box filters the folder as you type; Enter searches every subfolder too (from This PC, every drive). All words must match, * and ? work like in Explorer, and "quotes" keep spaces. Filters narrow it, as in Everything: ext:pdf (or ext:jpg;png), size:>10mb (>, >=, <, <=; kb, mb, gb), dm:7d (changed in the last 7 days; h, d, w, y) or dm:>1y (longer ago), file: and folder:. With instant search on, ext:iso size:>1gb on This PC lists every big ISO in milliseconds; the search box shows the filters when it's empty. Save keeps a search in the sidebar, to run it again with one click. The status bar says who answered: index · 18 found in 7.7 ms or fd · 304 found in 8.09 s. When nothing turns up, it says what was skipped, with a button each to look in hidden files, skipped folders or every drive.
• Plain words work too. Type pdfs from last week over 5 mb, photos taken in 2024, big zip files or songs by the beatles and the box reads them as filters, showing under it what it understood (PDF files · changed in the last 7 days · over 5 MB) and the filters that say it: Tab puts those in the box, so you learn the syntax by using it, and Enter still searches what you typed. It knows kinds of files, when they changed, sizes, and when photos were taken, with what, and who songs are by, all in the page, in microseconds, with nothing sent anywhere. Quick search reads them too.
• Photos, videos and music by what they say. width:>1920 and height:<1080 (pixels, as the picture shows, turned by its EXIF), taken:2024 (taken:2024-06, taken:>2023-06-15, taken:7d, taken:>1y), camera:pixel, duration:>5m (90s, 1:30), artist: and album: filter by what the files themselves say: their EXIF, video tracks and tags, the same details the preview shows and Date taken sorts by. Typing one filters the folder as each file is read; has the index or fd find the photos, videos or songs below it and reads them four at a time, each file once a session, so over a photo library is a filter and then a read. Each one keeps to the files it can be true of ( to songs, to pictures and videos), and the search box lists them when it's empty.

Tabs and dual pane

• Tabs. Ctrl+T opens a tab on the folder you're in, and tabs drag: along their strip, or onto the other pane's. A middle-click (or Ctrl+Enter) opens a folder in a new tab behind the current one, as in a browser. Ctrl+Tab and Ctrl+1…Ctrl+9 switch, Ctrl+W closes, and Ctrl+Shift+T brings the last one back. Each tab keeps its own history, selection, search and scroll position, and your tabs come back when the app starts (Settings → Reopen my tabs). A folder opened from File Explorer or a terminal (Glint.exe C:\Projects) gets a new tab in the window that's open: Glint runs once.
• Dual pane. Ctrl+Shift+D (or the toolbar button) shows two folders side by side, each pane with its own tabs. Click a pane or press F6 to work in it. Drag files across, or use Copy to other pane and Move to other pane, which run on Windows' own file engine like every other file operation.
• Compare the panes. Ctrl+Shift+M (or the toolbar button) opens the second pane if it's closed and marks each item that's only in one pane, newer, older, or the same date with a different size; the matches are dimmed. Diffs only hides them, Select picks every difference, and Sync copies what's only here or newer into the other pane through Windows' file engine (Ctrl+Z takes it back). Dates within 2 seconds count as equal, and folders compare by size once both are measured.
• Compare two files. Select two files and right-click Compare the two files (or Ctrl+K), or right-click a file the other pane has too. Text shows side by side, with each change's lines tinted and what changed in them marked, and Alt+Up/Alt+Down go from change to change. With Difftastic installed (one click, with winget) code is compared by its structure: a line reflowed or re-indented isn't a change, and only the tokens that changed are marked; without it, line by line. Pictures show side by side, with a swipe or an onion skin over each other; any other two files as bytes in hex, with where they first differ (or "the same, byte for byte") and Next difference. A changed file's Changes view opens its last commit's version against it the same way, with Side by side.
• Down through subfolders, and by contents. The compare bar's options: compares what's inside folders as well, so a folder differs when anything in it does, and then copies what's missing or newer inside them, each file into the folder it goes in. reads files of the same size on both sides rather than trusting their sizes and dates. Both skip what Find files skips (, ), and leave links to other folders alone.

Grid view

The List and Grid buttons in the command bar (or Ctrl+Shift+6 and Ctrl+Shift+2, as in Explorer, or Ctrl+K) switch the tab you're in; each tab keeps its own view, and new tabs start in the view of the tab they came from. The grid works like the list: click, Ctrl and Shift to select, arrow keys in all four directions, Enter to open, Space for Quick Look, F2 to rename, drag and drop (into the other pane too), the right-click menu and folder sizes under each folder. Sort it from the bar above it.

Zoom it as you would Explorer's icons: Ctrl and the mouse wheel over the grid, Ctrl+= and Ctrl+- (Ctrl+0 for Medium again), the arrow next to the Grid button, or Ctrl+K (large tiles). There are five tile sizes, from Small (64 px pictures) to Huge (256 px), and they grow with the text size too. The size is a setting (Settings → Files), so every grid has it, in both panes and every tab. A grid keeps its place as it zooms: the focused tile stays where it was on screen (otherwise the tiles at the top stay at the top), and the pictures already there grow or shrink at once while sharp ones for the new size come in.

Thumbnails come from Windows' thumbnail cache, the one Explorer fills, so pictures you've seen in Explorer are there at once (30 in 71 ms). Only the tiles on screen ask for one, and they stop asking when you scroll past them or leave the folder. What Windows doesn't have yet is made on worker threads below normal priority: photos that Windows' own photo provider decodes with its built-in codecs (JPEG, PNG, GIF, TIFF, BMP) on several threads at once, and everything else (videos, documents, fonts, HEIC and RAW photos, or pictures another app took over) by its own handler, where Windows runs it, usually an isolated process. Windows caches the result, so next time it's instant, and online-only OneDrive files are only shown when Windows already has their thumbnail, so nothing downloads. The status bar says how many came, how fast and from where. Where Windows makes none, Glint makes its own: a PDF's first page, drawn by Windows' own PDF renderer when no PDF app put in a thumbnail handler, and SVGs, drawn by the app itself, crisp at any tile size, text and all. JPEG XL pictures show through Windows' codec, once its JPEG XL extension is installed.

Bigger tiles ask for bigger thumbnails, one screen pixel to one (Huge at 125% scaling asks for 320 px). Windows keeps each thumbnail at a few sizes (96, 256 and 768 px among them) and answers with a smaller one when it lacks the size asked for, so those are made at the size the tile needs: a photo first seen in the list (32 px there) isn't stuck that small in the grid. Folders of 60 and 300 photos are on screen in 7–9 ms at every size, and their thumbnails come in this fast (status bar, fresh start of the app each run, default window at 125% scaling; median of 5 runs from the cache, 3 of never-seen photos):

Tile size	Thumbnails on screen	From Windows' cache	Never seen
Small	49	89 ms	238 ms
Medium	30	70 ms	241 ms
Large	24	66 ms	231 ms
Extra large	15	61 ms	165 ms
Huge	8	51 ms	137 ms

Disk usage map

Disk usage (in the command bar, or Ctrl+K) draws the open folder as a squarified treemap, the way WizTree and WinDirStat do: folders nest six levels deep, files are colored by type, and the 20,000 biggest items are drawn, with everything smaller grouped in its folder. Hover for the name, path and size, click a folder to go into it (or a file to go to its folder), Backspace or Alt+Up to go back out, Enter to open, and right-click for the usual menu.

Type and Age (or T) switch the colors between kinds of file and how long ago each changed, from today (hot) to over a year ago (frozen).

Growth colors what changed in the last day, 7 days or 30 days: folders that are new, doubled, grew, stayed the same or shrank, and files written to since. A line above the map says where it went ("Local Disk (C:) grew 14.2 GB since Fri, Oct 16 · Docker\wsl +9.1 GB · Downloads +3 GB"), and hovering a folder says what it was ("Was 2.1 GB on Fri, Oct 16 · +1.4 GB"). It comes from instant search: once a day its service takes a mark, and a folder's size is noted just before its first change after a mark, so every folder's size at each of the last 40 marks is exact while only the folders that changed take room.

With instant search on, the map comes from the index in one request: all of C:\ is on screen 53 ms after the click. Otherwise pdu measures the folder: going into a folder shows its part of the map while pdu measures it, and going back out shows the map you left. Each tab has its own map, and the status bar shows which engine drew it and how long it took.

Archives

Press Enter on an archive (or double-click it, or middle-click for a new tab) and it opens like a folder, in the list or the grid, in either pane and any tab: go into its folders, back up out of it, Back and Forward, the path in the address bar (C:\Downloads\photos.zip\2024\summer, typed or pasted too), and its tabs come back when the app starts. An archive inside an archive opens the same way. That's zip, 7z, RAR and cabinet (.cab) files, tars (.tar, and .tar.gz or .tgz, .tar.xz, .tar.bz2, .tar.zst, .tar.lz4), and single compressed files (.gz, .xz, .bz2, .zst, .lz4), which open as a folder holding the file.

Glint reads only the archive's own list of entries (the zip central directory, the 7z header, a tar's headers), once, and keeps it in memory: a zip of 50,000 files lists in 57 ms, and every folder in it after that in 0.2 ms. A compressed tar keeps no such list, so the first time it's opened it's decompressed from start to end, with progress and Stop. Every folder shows its size, and name search, folder sizes and the disk usage map work inside archives too. Previews, Quick Look and thumbnails extract only the file they show, to a temp copy that goes when you close the app, and opening a file opens a read-only copy of it.

Files that are zips by another name (Word, Excel and PowerPoint documents, .jar and .apk files, NuGet and VSIX packages, EPUBs…) and Windows Installer packages (.msi) still open in their app, or run, on Enter; right-click Open as archive to look inside. An installer package shows what it installs, laid out as the folders it installs into (Program Files (x86)\Contoso\app.exe), read from its cabinets without running anything. A file found to be an archive by its first bytes, under any name, opens too.

An ncdu export (ncdu -o, as a .ncdu file, or a .json one from its preview) opens as the disk it describes, scanned somewhere else, with its folder sizes, search and the disk usage map; its files are names and sizes only. Right-click a folder → Export as ncdu JSON… writes one of a folder here, for ncdu or Glint to open later.

Archives are read-only: what would change one is greyed out, with a Read-only archive badge in the command bar. Copy, Copy to other pane and dragging out extract the selection, folders and all, then let Windows' own file engine copy it, so progress and Replace or Skip are Windows' own. Paths can't escape the folder they're extracted to (no zip slip), entries are cut off at their declared size, zip bombs (huge expansion ratios, overlapping entries, oversized 7z headers) are refused, password-protected entries say so, and a damaged archive is an error, never a crash. Methods, limits and the temp folders: docs/archives.md.

Right-click Extract here on an archive unpacks all of it, with the same checks, into a new folder next to it named after it, as Explorer's Extract All does (a single compressed file comes out as the file, next to it). Compress to zip file packs the selection into a zip next to it (Deflate, with the files' dates), named after the first item and ready to rename. Both show progress, can be stopped, leave nothing behind when they fail, and Ctrl+Z takes them back.

Tools

In the command bar's Tools menu, a folder's or a file's right-click menu, and Ctrl+K. A tool that needs a program Glint doesn't ship installs it with one click, for your account only (Settings → Tools lists them all; which ones, and where they go):

• Find duplicates. Files of the same size are compared by their first and last 4 KB, then by a BLAKE3 hash of all their content, so a folder of thousands of files is checked in moments. Keep one copy of each and move the others to the Recycle Bin, or replace them with hard links to the one you keep: every path stays and the space is freed, but the copies become one file, so changing any of them changes them all. Each copy is compared with the kept one byte for byte right before it's linked, and cloud (OneDrive) files are left alone. On a drive that clones files (ReFS, or a Dev Drive), Clone takes the place of hard links: each copy becomes a block clone of the one you keep, sharing its space until one of them changes, yet a file of its own with its own dates and attributes. The clone is compared byte for byte with the copy it replaces before it takes its place.
• Clean up. What can go to free space below a folder, in four tabs. Developer junk: build output and package caches that a project's own tools make again (node_modules and .next beside a package.json, Rust's target beside a Cargo.toml, .NET's bin and obj beside a project file, Python virtual environments and caches, and the build folders of Gradle, Maven, CMake, Unity, Unreal, Flutter, Swift, Elixir, Haskell, Zig, Godot, Elm and Terraform), each with when its project last changed (its build output and .git aside), so Projects untouched for 30 days picks the ones you've left alone. A folder that only shares the name (a target folder of photos) is left out, and so is a link to one (a worktree's node_modules). Empty folders: nothing in them, down through their subfolders. Temporary files: what programs leave behind (.tmp files, Office's ~$ owner files, Thumbs.db, .DS_Store), less what a program still has open. Big files: 100 MB to 10 GB and up, biggest first, grouped by type. With Czkawka (one click installs it, with winget): look-alike pictures (resized, converted or re-saved copies, with thumbnails and Keep the biggest), look-alike videos (FFmpeg reads them), the same music by its tags or by how it sounds, broken files with why they don't open, and files with the , which get their real one. Hidden folders aren't looked in for empty folders or big files, nor AppData for big files (WSL's and Docker's disks there are whole systems), and Windows' own folder and the Recycle Bin never are. What you choose goes to the Recycle Bin, and brings it back. With instant search on, 103 folders of developer junk holding 58.6 GB under a here were found, sized and dated in 0.3 s; without it, fd finds them and pdu sizes them (7.1 s). Also on the disk-usage map, as .

These work on files on disk, not inside archives.

Instant search (NTFS index)

It's off until you turn it on: on This PC, with the status bar's Turn on instant search, or in Settings → Instant search. Windows asks for administrator approval once, and a small service indexes your fixed NTFS drives. It reads each drive's Master File Table in one sequential pass (2.3–2.5 s for C: with 2.9 million records here), then follows the USN journal, so a file created, renamed or deleted anywhere is in the index within about 0.3 s. Name searches, folder sizes and disk-usage maps then answer from memory. fd and pdu take over wherever the index can't answer: network shares, FAT and exFAT drives, and searches that read .gitignore.

The service only runs once you opt in, with every privilege removed except the three it needs. It answers only you and administrators, over a named pipe no other program can pose as. It knows the names of all files on the indexed drives, including ones your account can't open, so on a shared PC turn it on only for accounts that may see every file name. Measurements, how it works and the full security model are in docs/instant-search.md.

AI agents

AI agents that speak the Model Context Protocol (Claude Code and Claude Desktop, VS Code's Copilot, Cursor and others) can use Glint's engines. Glint.exe mcp is the server: the agent starts it, and it answers on its standard input and output with five tools, which only read.

Tool	What it answers	How
search_files	Files and folders by name on every drive, by the search box's query (budget ext:xlsx dm:30d), the best matches first	The instant search index in milliseconds, fd where it doesn't reach
folder_sizes	A folder's total and each folder in it	The index, otherwise pdu
largest_files	The biggest files anywhere below a folder	The index's disk-usage map
recent_changes	What was renamed, moved, deleted or recycled lately, and where each item went	The index's 30 days of changes
search_text	Lines of text files that contain a pattern	ripgrep

Settings → AI agents has each agent's setup to copy: claude mcp add glint -- "C:\…\Glint.exe" mcp for Claude Code, code --add-mcp for VS Code, and the mcpServers entry for Claude Desktop, Cursor and the like. Once told, the agent starts Glint for itself and sees the names and text it asks for; Glint tells it that what files are named and contain is data, not instructions. Measured here, through the server as an agent asks: kernel32.dll on every drive in 8 ms, C:\Windows's folder sizes in 1 ms, the biggest files on C:\ in 41 ms.

Text: search inside files (ripgrep)

• ripgrep speed. Results stream in as rg finds them.
• Search and replace across many files at once, matching line by line as ripgrep searched (^ and $ mean a line's start and end, CRLF files included), each file written safely: a write cut short leaves it as it was.
• Results that fold. Click a file to fold its matches away, or collapse them all at once; a bar on each file shows which have the most matches.
• Regex, case, whole word, exclusions. Full regular expressions (multi-line with Shift+Enter), case sensitivity, whole words, and patterns to skip (node_modules, .git…).
• Code patterns. Alt+A searches code by its structure rather than its text, with ast-grep (installed with one click): console.log($$$ARGS) finds every call however it's spaced or split over lines, $X.unwrap() every unwrap, in 20-odd languages. With a rewrite in the replace box (logger.info($$$ARGS)), each result first shows what it becomes; Replace all again rewrites them in the files.
• Documents. Alt+D searches the text inside PDF, Word, Excel, PowerPoint, OpenDocument and EPUB files, with the same case, whole-word and regex rules, without Office or a search index. Each result says where it is ("p. 12", "slide 3", "Sales, row 40") and the preview shows the text around it.
  • PDFs are read by pdf-extract, the rest from their own XML; scanned PDFs, which hold pictures of text, have none to find.
  • Documents are read by Glint's own worker processes, up to four at a time, each limited to 1 GB and 30 seconds a document, so a damaged or hostile file can't take the app down. The results say how many couldn't be read.
  • What's read stays in memory for the session (up to 256 MB), so searching the same folder again is quick; none of it is written to disk.
  • Pictures too (Alt+O, with Documents) reads the text in pictures as well, with Windows' own OCR (in the languages your Windows has it for): PNG, JPEG, TIFF, BMP and GIF, and WebP, HEIC and AVIF with Microsoft's extensions for them. A scan or a screenshot is then found by what it says, and each result is its line.
  • Skipped: hidden files and folders, the excluded folders, and files kept only in the cloud (reading them would download them). File patterns like among the exclusions keep binary files out of text searches and don't apply here. Replace works in text files only.

Compared with File Explorer

	File Explorer	Glint
Folder sizes	In Properties or a tooltip	In the list, for every folder
What fills a drive	Not shown (Storage settings has categories)	A treemap of any folder, like WizTree's
Find a file by name	Windows Search where it indexes, otherwise a walk through every folder	An index of every NTFS drive (opt-in), otherwise fd
Search inside files	Indexed places and file types	ripgrep in any folder, with regex and replace; code by its structure; PDFs' and Office documents' text too, by words or by meaning
Preview	Preview pane	Preview pane with the same previewers, and its own: Markdown as it reads, JSON and YAML as trees with jq, tables with SQL, databases, programs, every file's bytes; Quick Look on Space
Git	Not shown	Each file's and folder's status, the branch in the address bar, and what changed in a file
Compare two folders	Not available	Side by side, down through subfolders and by contents, with Sync
Compare two files	Not available (fc in a terminal)	Side by side: code by its structure (Difftastic), pictures with a swipe, any file byte by byte
A search from anywhere	Windows Search in the Start menu	Ctrl+Alt+F: every drive's names, answered by the index as you type
Go to a folder	Quick access, address bar	Address bar, and Ctrl+K with your most-used folders
Tabs and panes	Tabs (Windows 11)	Tabs in each pane, and two panes side by side
A terminal	Open in Terminal, in a window of its own

Install

Get Glint from the Microsoft Store. Microsoft signs the Store's copy, so Windows installs it without a warning, even with Smart App Control on, and the Store keeps it up to date. It's the same Glint, apart from what Windows doesn't let Store apps do: change File Explorer's settings, so Open in Glint on File Explorer's menu, Open folders in Glint by default and Win+E opens Glint need the installer's copy. The two keep their settings apart; Settings → About → Settings file moves them across.

Or download the installer and open it. It installs for your account in a few seconds, without administrator rights, with ripgrep, fd and pdu inside. Its Extra tools page offers the rest, each with what Glint uses it for: instant search, and the free tools some features need (which ones), which you can also add later in Settings → Tools. Each installs with or without winget: from its own release, checked against its checksum, where winget isn't. Windows 10 or 11, 64-bit, with Microsoft Edge WebView2, which Windows 11 has: where it's missing, the installer adds it, and so does Glint when it starts (a Scoop or copied install too).

The installer isn't code-signed yet, so Windows may say Windows protected your PC: choose More info, then Run anyway (why). If your browser holds the download back because the file isn't commonly downloaded, choose Keep. With Smart App Control on, Windows doesn't run it at all: get Glint from the Microsoft Store there.

From then on the installer's Glint updates itself: when a new version is out, it says so, and Install (in that notice or in Settings → About) downloads it, checks its signature and restarts into it in a few seconds.

Glint was called ShadUI Ripgrep before 0.3.1. Installing Glint replaces ShadUI Ripgrep and keeps your settings, tabs and instant search.

With a package manager

winget installs the Microsoft Store's copy:

winget install 9NQLRJ3HF1C9 --source msstore

Scoop checks the download against its hash and doesn't trigger SmartScreen. It keeps Glint up to date itself (scoop update glint), and the app only tells you a new version is out:

scoop bucket add shadijhade https://github.com/shadijhade/scoop-bucket
scoop install shadijhade/glint

The installer's own winget package, once microsoft/winget-pkgs#455306 is merged (new packages wait about six weeks for a moderator there):

winget install shadijhade.Glint

Keyboard shortcuts

Files

Key	Action
Enter	Open the selection (an archive opens like a folder)
Space	Quick Look: the focused item full size. Arrows move through the folder; Space or Esc closes
Ctrl+K / Ctrl+P	Command palette: folders you use, paths and every command (= and a sum works it out)
Shift+right-click	Windows' own context menu (also Show more options in Glint's)
Tab in the search box	Put in the filters the plain words stand for (pdfs over 5 mb → ext:pdf size:>5mb)
Ctrl+T / Ctrl+W	New tab on this folder / close the tab
Ctrl+Tab / Ctrl+Shift+Tab · Ctrl+1…Ctrl+9	Next / previous tab · go to a tab (Ctrl+9: the last one)
Ctrl+Shift+T	Reopen the last closed tab
Middle-click a folder / Ctrl+Enter	Open it in a new tab
Ctrl+Shift+D	Dual pane on or off
Ctrl+Shift+M	Compare the two panes
F6	Switch to the other pane
Ctrl+`	Show or hide the terminal under the files (the first one opens in the folder shown)
Alt+Left / Backspace · Alt+Right · Alt+Up	Back · Forward · Up
Ctrl+L / Alt+D /

Disk usage map

Key	Action
Click	Go into a folder; on a file, go to its folder with the file selected
Backspace / Alt+Up	Back out to the folder above
Alt+Left · Alt+Right	Back · Forward, as in the list
Enter / double-click	Open the selected item (a folder is mapped)
Space	Quick Look the selected item
Right-click	The item's menu, as in the list
F5	Map the folder again (measures it again when pdu drew it)
T	Color by kind of file, by age, or by what grew

Text search

Key	Action
Enter	Search (in the search box) / open the selected result
Shift+Enter	New line in the search box (multi-line search)
Arrow Up/Down	Move through results (Down in the search box goes on to them)
Ctrl+F / Ctrl+K	Focus the search box
Ctrl+H	Show or hide Replace
Alt+C / Alt+W / Alt+R	Toggle match case / whole word / regex
Alt+A / Alt+D / Alt+O / Alt+M	Toggle code patterns / documents / pictures too (OCR) / meaning
Ctrl+Shift+E	Back to Files
Esc	Leave the search box; again, stop a running search; close menus and dialogs

F1 (or Ctrl+/) shows every shortcut on one sheet, Ctrl+, opens Settings from anywhere in Glint, and Ctrl+Alt+F opens quick search from any app (Settings → Quick search picks another shortcut, or none).

How it works

• Folders: one FindFirstFileExW pass (basic info, large fetch) gets every name, size, date and attribute at once. Rust sorts them and hands the whole listing to the UI as a single binary buffer rather than JSON, and React draws only the rows on screen.
• Name search: the instant-search service when it covers the folder, otherwise fd, with results streamed into the list as they arrive.
• Folder sizes: the index's per-folder totals, otherwise pdu. It took over from dust, giving the same totals 14–30% faster: the subfolders of C:\Windows are sized in 4.9 s instead of 6.9 s, and its map is measured in 4.7 s instead of 6.7 s (warm cache, the median of 5).
• Thumbnails: Windows' thumbnail cache through IShellItemImageFactory (thumbnails only, from the cache only: about a millisecond each), on worker threads that are each a COM apartment of their own. What the cache doesn't have is made by the file type's thumbnail handler: Windows' photo provider runs on our own threads with IThumbnailCache and WTS_EXTRACTINPROC (220 a second with 8 threads, where the isolated process Windows uses for other handlers makes about 50 however many ask), and Windows caches each one as if Explorer had made it. Requests wait in their tab's queue, shared between panes showing the same file, and are dropped when the tiles asking for them scroll away. Each tile asks at its size in screen pixels; when the cache answers with a smaller size it has (it keeps 16 to 2,560 px versions), the thumbnail is made at the size asked, and the smaller one is the answer only for online-only files or when making fails. Each answer reaches the UI as one binary buffer, an uncompressed BMP, and both sides keep the latest ones in memory.
• Disk usage map: one request to the index returns the biggest files and folders six levels down (folders are walked biggest first, so nothing too small to draw is looked at), or pdu's JSON tree when the index doesn't have the folder. Either way it reaches the UI as one binary buffer and is drawn on a canvas as a squarified treemap. For all of C: here (464 GB, 2.9 million MFT records) the service answers in 19 ms for the 20,000 biggest items six levels down, and the map is on screen 53 ms after the click; on a synthetic index of 2.86 million records it takes 9–17 ms, whether the map goes 4 or 32 levels down.
• Archives: zip reads a zip's central directory, served from memory in one read of the file's end (13 ms for 50,000 entries, where reading it from the file takes 150 ms), and sevenz-rust2 reads a 7z's header, once Glint has checked how big it unpacks to. Tars and cabinets are read by Glint's own readers, and gzip, xz, bzip2, Zstandard, LZ4 and LZX by pure Rust decoders. RAR is read with RARLAB's UnRAR (C++), which only ever tests files and hands their bytes over; everything else is pure Rust. The entries become a tree of folders kept in memory, with safe Windows names and folder totals, and each listing reaches the UI as the same binary buffer as a folder's. A file is extracted only when it's previewed, opened or copied, cut off at its declared size, and copies out go through from a staging folder. See .

Built with Tauri 2 and the windows crate on the Rust side, and React, Vite, Tailwind CSS, shadcn/ui, Lucide and Zustand in the UI. The bundled tools:

Tool	Version	Used for	License
ripgrep	15.2.0	Searching inside files	MIT or Unlicense
fd	10.5.0	Finding files by name	MIT or Apache-2.0
pdu	0.24.0	Folder sizes and disk-usage maps	Apache-2.0

Build from source

You need Windows 10 or 11, Node.js 22.18 or newer, Rust (stable, MSVC toolchain) and the Tauri prerequisites.

git clone https://github.com/shadijhade/glint.git
cd glint
npm install
npm run tauri dev

npm run tauri build makes the installer in src-tauri/target/release/bundle/nsis/. The Windows x64 builds of ripgrep, fd and pdu ship in src-tauri/binaries/; on other platforms, add binaries named rg-<target-triple>, fd-<target-triple> and pdu-<target-triple> there. npm run release, or the release workflow when a version tag is pushed, builds a release on top of that: the update package the app installs, code signing, and the winget and Scoop manifests (docs/releasing.md).

The checks to run before you commit:

npm run build
node src/lib/explorer.check.ts
node src/lib/text.check.ts
cd src-tauri && cargo clippy --workspace --all-targets -- -D warnings && cargo test --workspace

Release builds run once per app identifier, so a release build of Glint hands its folders to an installed Glint that's running. Try them under a name and identifier of their own (docs/explorer-integration.md).

The index's tests (MFT record parsing, queries, disk-usage maps, folder totals under random changes, snapshots, the wire format, and a real named-pipe round trip with its ACL) run without administrator rights.

Roadmap

• Tabs and a dual-pane view
• A disk-usage map (treemap) from the index
• Thumbnails and a grid view
• Auto-update, with signed update packages
• A Scoop package
• Code-signed installers (the SignPath Foundation invited a new application once Glint is better known)
• The winget package (in review: microsoft/winget-pkgs#455306)
• The Microsoft Store, signed by Microsoft
• Zip, 7z, RAR, cabinet and tar archives (compressed too) opened like folders, Extract here, and Compress to zip
• Undo (Ctrl+Z) for copies, moves, renames, deletes and new items
• Quick search from anywhere (Ctrl+Alt+F), the tray, and starting with Windows
• Word, Excel, PowerPoint and font previews through Windows' previewers
• Comparing folders down through subfolders and by contents, with Sync
• A terminal under the files that follows the folder shown
• The Recycle Bin as a place: restore with Undo, delete for good, empty
• Git status, the branch and what changed, in every folder of a repository
• Previews of Markdown, JSON and YAML trees with jq, workbooks and Parquet with SQL, and every file's bytes
• Searching inside PDFs and Office documents, by words or by meaning, and code by its structure

Missing something? Open an issue. If the app saves you time, a star helps other people find it.

Contributing

Bug reports, ideas and pull requests are welcome. CONTRIBUTING.md covers the setup, where things are in the code, and the checks. To report a security issue, see SECURITY.md.

Acknowledgments

• fd, pdu and ripgrep, which do the heavy lifting and ship inside the app.
• The tools Glint installs when a feature needs them, Czkawka, Difftastic, ast-grep, jaq, YARA-X, Kingfisher, rimage, sendme, dufs and more (docs/tools.md), and the crates it's built from (THIRD_PARTY_CRATES.md).
• Everything and WizTree, which showed that reading the MFT directly is the fast way, and goz and everyfind, whose ideas the index service borrows.
• zoxide for frecency, and macOS for Quick Look.

License

MIT, see LICENSE. The bundled ripgrep, fd and pdu, and the crates that read archives, keep their own licenses; see THIRD_PARTY_LICENSES.md, and THIRD_PARTY_CRATES.md for every crate in the app.