Sort Files by Extension into Folders

Drop in a folder or zipped repo and get back a ZIP organized into one folder per file extension.

A downloads folder full of years of stray installers, screenshots, and half-remembered zips is exactly what this exists to untangle. It reads a .zip archive or an entire folder pick, groups every file by its extension, lets you review and filter the full listing before anything is written, and hands back a new zip organized into one folder per extension — without silently absorbing the .git history or node_modules tree that came along for the ride.

How to sort files by extension

  1. Click Choose a .zip archive, or Choose a folder to open your browser's directory picker, which reads every file inside at any depth.
  2. Review the crawled table of paths, extensions and sizes, along with the file count, total size, number of distinct extensions and how many files remain after exclusions.
  3. Adjust the exclusions: untick any pre-checked folder you want kept, add your own path patterns one per line, or drop a whole extension bucket such as log.
  4. Click the Sort button, which states how many files it will place into extension folders, then download the resulting archive named after your source, e.g. Downloads-sorted.zip.

Two ways in, one review step before anything happens

You can hand it a .zip archive directly, or pick an entire folder using the browser's folder-selection input, which reads every file's path and size without uploading any of it. Either way, nothing gets bucketed or written until you've seen the full crawled listing — a sortable, filterable table of every path, its detected extension, and its size — so a folder that turns out to be the wrong one, or one much larger than you expected, is obvious before you commit to sorting it.

Bucketing itself is a simple rule: a file's lowercase extension becomes its output folder name, and a file with no extension at all — including a dotfile like .gitignore, where the leading dot is the whole name rather than an extension separator — goes into an explicit no-extension folder rather than being merged into some other bucket by accident.

What the sorted ZIP looks like

The output archive has one top-level folder per extension and nothing else. Subfolders from the source are flattened away, so only each file's own name survives inside its extension folder. Take a source holding report.pdf, 2023/report.pdf, photo.JPG, .gitignore and Makefile: the result contains pdf/report.pdf, pdf/report-2.pdf, jpg/photo.JPG, no-extension/.gitignore and no-extension/Makefile.

Folder names use the lowercased extension, so photo.JPG and scan.jpg land together in jpg/, while the files themselves keep their original capitalization. When two files with the same name meet in one folder, the first keeps its name and later ones get -2, -3 and so on before the extension.

Exclusions that are already checked, and ones you add yourself

How a pattern actually matches

A pattern written with a trailing slash, like node_modules/, matches that name as a path segment anywhere in the tree regardless of nesting depth — so it correctly excludes packages/app/node_modules just as readily as a top-level one. A pattern with no trailing slash instead matches an exact filename, so Thumbs.db excludes files with that specific name wherever they appear, without accidentally matching something like Thumbs.db.bak.

This starting set of default exclusions is meant as a sensible baseline for a messy download or an unfamiliar codebase archive, not a hard-coded floor — every checkbox can be unchecked if you genuinely want those files sorted too.

Why the output zip builds fast even on a big archive

When the source is itself a zip file and an entry's original compression method already matches the output archive's compression setting, its compressed bytes are copied straight into the new archive without ever being decompressed and recompressed. Only entries that need to change compression method, or that came from a folder pick rather than a zip, go through the normal read-decompress-recompress path. That distinction is what keeps re-sorting a large, already-compressed archive fast rather than paying the full compression cost twice.

Who sorts files by extension, and why

Limits worth knowing before you load a huge folder

There's a practical ceiling of 750 MB of total input size and 50,000 individual entries, checked against the full crawled listing before sorting is allowed to proceed — a folder past either limit gets an explicit message rather than a browser tab that silently runs out of memory partway through. The check counts everything the crawl found, including files your exclusions would later drop, and for a zip it adds up the uncompressed sizes. Everything else — crawling, filtering, bucketing, and building the output zip — happens entirely in your browser's memory with no upload step at all.

Questions people ask about File Extension Sorter

Will this accidentally include my .git folder or node_modules in the sorted output?
Not by default — both are pre-checked exclusions in the standard list, along with common build-output folders like dist, build, and target. You can still uncheck either one if you actually want those files sorted, but out of the box neither ends up in the output zip.
What happens to files that don't have a file extension?
They're grouped into an explicit no-extension bucket rather than dropped or merged into another folder. A dotfile like .gitignore counts as having no extension too, since its leading dot is the entire filename rather than separating a name from an extension in the usual sense.
Is there a size limit on the folder or zip I can sort?
Yes — 750 MB of total file size and 50,000 individual files, whichever is hit first. Going over either limit is flagged with an explicit message before sorting starts, rather than letting the browser tab try to process it and potentially run out of memory partway through.
Does sorting a large zip take a long time because everything gets recompressed?
Usually not. When an entry's original compression already matches the output setting, its compressed bytes are copied straight into the new archive without decompressing and recompressing it — only entries that genuinely need to change format, or that came from a folder pick, go through the slower full read-and-recompress path.
Are my files uploaded to a server?
No. The zip or folder is read by JavaScript running in this tab, and the sorted archive is assembled in memory and handed to you as a local download link. No file name, path or byte of content is sent to BrakeTools or anywhere else.
Does sorting rename or change my files?
File contents come through byte for byte and keep their modified dates. Names stay the same unless two identical names collide in one extension folder, where later copies get a -2 or -3 suffix. Your original folder or zip is only read, never altered.
What does the sorted ZIP folder structure look like?
One folder per extension at the top level, such as pdf/, jpg/ and no-extension/, each holding the matching files directly. The source's own subfolders are not recreated inside them, so a file's original path is not preserved in the output.

Related tools on BrakeTools

Content reviewed 2026-09-27.