Flut Renamer: bulk renaming with a rule pipeline and a preview

A Flutter renamer with a name that explains itself

Flut Renamer is described as an easy-to-use tool designed to help users manage and rename files and directories, and the point of it is that you no longer rename things one by one. The features are described as inserting text, file metadata and Exif data, replacing text, deleting text, rearranging, and more, so that you can quickly batch rename files according to your needs.

The name is explained in the README and it is a good name. Flut is derived from Flutter, indicating that the app is built using the Flutter framework, and Flut means flood or tide in German, implying that the app can batch rename files as swiftly as floods or tidal waves.

The interesting decision is the platform list. The same application is built for Android, Linux, Windows, macOS and iOS, and a bulk renamer is exactly the kind of utility that people want on a phone as well as on a desktop, because a camera roll is the largest pile of badly named files most people have. The feature list adds system light and dark themes and twelve interface languages, and it states plainly that the app is free and open source, without advertisements or in-app purchases.

The project is Dart, licensed GPL-3.0, on the main branch, with the last push on 2026-10-15 and the recent releases v1.6.2 on 2026-08-28, v1.6.3 on 2026-09-19 and a v1.6.3-test4 on 2026-09-23.

Rules are a pipeline, and the preview is the point

The core interaction is a list of rules that you add, edit by clicking, and reorder by dragging a handle. Rules run from top to bottom, each using the previous rule's output, and the result is previewed before anything is applied.

That chaining is the design decision. A rename is rarely one operation, it is usually a sequence, take the base name, insert the date, replace the extension, add a number, and expressing that as a pipeline of small rules means you can reorder them, disable one, or reuse them in another project without rewriting anything.

The worked example in the README shows the numbering side of it. An Increment rule in Replace original name mode with the prefix Photo, a start index of 1, a step of 1, three digits, Omit dash disabled and Ignore Extension enabled produces Photo-001.jpg, Photo-002.jpg, and so on. Insert into original name is the other mode, and it keeps the original name and inserts the number with surrounding text at a chosen position.

The numbering controls are the ones worth knowing: a configurable starting number, a step, zero padding, a prefix and a suffix. And there is a subtlety the README calls out, which is that you should sort by name, size, date or type before committing a numbered sequence, because changing the list order recalculates the numbering. That is what makes the sort control part of the renaming interface rather than a browsing convenience.

Metadata and transliteration as sources of text

The rules do not only transform the existing name, they can pull new text in from the file itself.

The feature list covers inserting file dates and sizes, photo EXIF fields, and audio tags such as artist, album, title and track number, with the caveat that metadata availability depends on the file format and the storage provider. That caveat is doing real work, because a file on a network share or in a container may not expose the tags the same way a local file does.

The transliteration options are the other half of the feature set. You can convert letter case, convert between simplified and traditional Chinese, convert Chinese to pinyin, and convert supported Cyrillic languages to and from Latin characters. The word supported is doing the work there too, since transliteration tables are finite and the README does not claim more than that.

Alongside those there is the housekeeping the feature list mentions: sort and filter the file list, rename only selected rows, and save reusable rules as YAML.

So the range of operations is: insert, replace, remove, number, rearrange, transliterate and truncate, with text coming either from the name or from the file's own metadata.

The rename scope, and why the summary matters

The quick start has a step that deserves more attention than it gets, which is the choice of rename scope. There are three: Current filtered results, which is the default, All loaded items, and Selected items including hidden.

The definitions are precise. The file-type dropdown and the text filter determine what counts as current filtered results, and the header checkbox selects or deselects only visible rows. All loaded items and Selected items including hidden can include hidden rows, and the README asks you to check the scope summary before pressing Rename, because the summary shows the target count and how many targets are hidden.

That is a real safety feature. A user who has filtered the list down to forty items, expecting forty renames, can easily have a filter that hides most of the loaded files, and a scope of all loaded items would then rename far more than expected. Showing the count and the hidden number is the cheapest possible defence.

The other details in that step are subtle in the same way. An empty scope disables the rename button. Numbering follows the full list order and keeps the previewed values, so filtered or selected subsets may contain gaps in the sequence. The previous Only selected preference is preserved as the selected scope, and otherwise each new session defaults to current filtered results.

And the last step separates the two things that are easy to confuse. Remove renamed files removes successful rows from the list, not from disk, and View Log shows the recent rename operations.

Rules as YAML, and the spreadsheet round trip

The rules are portable, and the README is careful about how.

Save Rules exports the current rules to a .yaml or .yml file, and Load Rules replaces the current rules with those from the selected file. On desktop, dropping YAML files onto the rule list gives you a choice: insert them before or after the existing rules, or replace the list entirely.

There is a warning attached to the automatic caching. Rules are cached automatically for restoration, but the operating system can clear this temporary storage, so you are told to export the rules you want to keep. Rule files store renaming instructions, not copies of your files, which is the right design and also the reason a lost cache is not a disaster.

The other direction is a spreadsheet workflow, and it is described step by step. You add the source files or directories and choose the rename scope. You open the table menu beside Rename scope and choose Export current preview as CSV, which exports the current scope with UTF-8 encoding and a BOM for spreadsheet compatibility. You edit the new_name column in a spreadsheet editor, keeping the source column as text, and save as UTF-8 CSV or UTF-8 TSV.

The two limits are stated plainly: Excel .xlsx files and semicolon-separated CSV are not accepted directly. That is a sensible restriction for a tool that has to read the file back, and it is much easier to honour than to be vague about it.

Five platforms, and the ones that are not signed

The install section is where the project is most honest about itself, and the interesting parts are the limitations.

Packages come from the releases, the assets vary by release and you choose the one matching your operating system and CPU, and the release workflow also generates SHA256SUMS for verifying downloads.

On Linux the packaging supports AppImage, Flatpak, Deb, RPM, Nix and native tar archives for x86_64 and arm64, with Pacman packages built for x86_64, and the note that asset names using x86 refer to x86_64 and not 32-bit x86. The current native packages and AppImages are built on Ubuntu 24.04 and require glibc 2.39 or newer and GTK 3, and an AppImage does not bundle every system library.

On macOS the current builds target macOS 12.0 or later, and the release build is unsigned and not notarized, and installing through the Homebrew cask does not change that. On iOS the current builds target iOS 15.0 or later, and the release workflow produces an unsigned ipa that must be signed through your chosen sideloading process before installation, so it is not a ready-to-install App Store package. On Windows you take the portable executable from the releases or install through the attached Scoop and Winget manifests. On Android there is a Google Play listing or an apk from the releases.

One clarification is worth repeating, because it is a common misunderstanding. The Homebrew, Scoop and Winget files are release attachments, and generating them does not publish the app to those managers' public repositories, nor does generating a Flatpak publish it to Flathub. The community AUR packages are separate again, with the names flut-renamer for a source build and flut-renamer-bin for a binary, and their maintenance and versions are independent of this repository's release workflow.

A Flutter project with a directory per platform

The top-level listing is the standard shape of a Flutter application, and a few entries say something about how the project is run.

There are the platform directories, android/, ios/, linux/, macos/ and windows/, and the shared code in lib/ with tests/ alongside it and integration_test/ for the end-to-end tests. The pubspec.yaml and pubspec.lock are the Dart dependency files, analysis_options.yaml configures the analyzer, and dart_test.yaml configures the test runner.

Then there are the packaging helpers that are not part of the Flutter template: appimage/, appimage_build.sh, github_appimage_build.sh, dmg/ and build.yaml, which are the AppImage and macOS disk image builds, fastlane/ for the store submissions, and the packaging/ directory whose README holds the installation commands and the package requirements for each platform. There is a license_checker_config.yaml, which tells you the project checks the licences of its dependencies, and a privacy_policy.MD, which a mobile application needs before it can be published to the app stores.

There is also a dev/ directory, a tool/ directory, a docs/ directory and a screenshots/ directory, and a .metadata file, which is the file the Flutter tool itself uses to know which project type it is looking at.

Taken together, the repository is a single Flutter codebase aimed at five platforms, with the release engineering kept in the tree rather than delegated to a separate automation repository, which is why the Linux, macOS and iOS packaging all have their own directories and scripts.

Editorial conclusion

Adopt Flut Renamer if you have a folder of thousands of files with a naming scheme you keep meaning to fix, because the chained rules and the preview make a destructive operation reviewable, and the scope summary tells you how many rows a rename will actually touch before you commit. Do not adopt it expecting a signed macOS or iOS build, because the README is explicit that the macOS release is unsigned and not notarised and that the iOS artefact is an unsigned ipa you have to sign yourself. Before you run it on anything that matters, export your rules to YAML, because the README says the automatic cache can be cleared by the operating system, and check the scope summary rather than trusting the filter, since the selected and all-loaded scopes can include rows the filter has hidden.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. sun-jiao/flut-renamer on GitHub