A Power User's Critical Review and Feedback on TagStudio Alpha 9.5.2

[Foadsf]

First, I want to commend the developer on the vision behind TagStudio. The YouTube videos are exceptionally well-made and eloquently explain the shortcomings of traditional file organization. The core concept—moving beyond simple folders and hashtags to a system of rich, relational tags—is exactly what I've been searching for. This review comes from a place of wanting to see this project succeed, but also from a position of honesty about why I cannot continue using it in its current state.

My Motivation: The Search for a "Single Source of Truth"

My digital life is a mess, spread across numerous cloud services (Google Drive/Photos/Keep, OneDrive), local drives, and dozens of external storage devices. Finding anything is a Herculean task.

My journey has included:

• Trying to enforce strict folder and file naming conventions.
• Using powerful command-line search tools like es.exe (Everything CLI), which are fast but limited to what's in the filename/path.
• Experimenting with symlinks, which are cumbersome and not portable.
• Trying other tools like TagSpaces (which I abandoned due to its move towards a proprietary model) and the limited tagging in the Files App for Windows.

I was drawn to TagStudio because it promised a solution that didn't rely on sidecar files (initially a plus for me) and offered a powerful, structured metadata system that could exist independently of the filesystem's limitations.

Installation and First Impressions

I installed Alpha 9.5.2 via winget on Windows. The process was smooth, though it didn't create a desktop shortcut, and Windows search struggled to find the app unless I typed the full name. This is a minor packaging/OS quirk.

My first impression of the UI was that it felt unfamiliar. While custom UIs can be powerful, for a utility designed to manage files, a layout that more closely resembles a familiar file explorer paradigm (e.g., a tree view for navigation on the left, items in the center, details on the right) would make initial adoption much more intuitive. The lack of dedicated tutorials exacerbates this; the YouTube videos are great for explaining the "why," but not the "how."

Core Architectural Concerns

After spending a few hours with the application, I ran into several architectural decisions that conflict with my ideal workflow.

1. The Single-Root Library Model

TagStudio libraries are tied to a single root folder. This is a significant limitation. My files are scattered across multiple folders, e.g., C:\Users\...\Documents, D:\Projects, E:\Archive, etc. The ideal system should allow me to add multiple, disparate folders into a single library or "vault," creating a unified view without me having to first reorganize my entire filesystem into one monolithic folder (e.g., Zotero).

2. The Centralized, Opaque Database

The library is stored in a ts_library.sqlite file. I have two major issues with this approach:

• It's a "Black Box": A binary SQLite file is not human-readable or easily manipulated by other tools. More importantly, it is not version-control friendly. I want to be able to track the history of my metadata using Git, which is impossible with a binary database.
• Location isn't User-Defined: The database is stored inside the monitored folder. I would prefer the option to store the database file in a separate location (e.g., a synced cloud folder like Dropbox or a private Git repository).

My strong preference would be for a system built on open, text-based standards. The semantic web stack offers a perfect model for this:

• Format: Turtle (.ttl) files are human-readable, highly compressible, and perfect for Git.
• Model: The Resource Description Framework (RDF) model of (subject, predicate, object) triples is infinitely more expressive than the current system.
• Schema: The Web Ontology Language (OWL) would allow for defining incredibly rich relationships between tags and files.

3. Limited Relationship Model

The current parent-tag system implements a simple "is a" or "belongs to" hierarchy (inheritance). This is a good start, but it's a small part of what's needed. An RDF/knowledge graph approach would allow for defining any kind of relationship (predicate). For example:

• (file:DSC_6645.jpg) (depicts) (person:Foo_Bar)
• (person:baz_qux) (author_of) (post:quux)
• (case:0123456) (handled_by) (institution:fooo)

This creates a true knowledge graph, not just a simple taxonomy, which is far more powerful for complex data.

Critical Usability Issues (Showstoppers)

Important

Beyond the architectural disagreements, there are fundamental usability issues in the current alpha that make it non-functional for its primary purpose.

1. Severe Performance Degradation

After importing a large directory, the GUI became extremely slow and sluggish. Every click was met with a noticeable delay, making the application frustrating to use.

2. The Search Function Is Broken

This is the single biggest reason I have to stop my evaluation. The search bar at the top of the application does not work.

• It does not find strings in filenames.
• It does not find tags that have been applied to files.
• It does not find text within the metadata fields I've added.

A file organization tool whose primary discovery mechanism—search—is non-functional, cannot be used. I had hoped for advanced search features (regex, complex inclusion/exclusion filters), but the complete failure of basic search makes the application's core premise of "rediscovering files" impossible to achieve.

Feature Gaps and UX Suggestions

• No Custom Field Types: The application offers a fixed list of fields (Text Line, Text Box, etc.). There is no way to define my own named fields (e.g., a "Case Status" field with a "Dropdown" type).
• Poor Handling of Filesystem Changes: When I rename a file in Windows Explorer, TagStudio simply marks the old entry as "unlinked." It makes no attempt to intelligently notice that a file with a new name but the same hash/size/date might be the renamed file. A more robust system would detect these changes and prompt the user to confirm the relink.
• Tag Manager UX: Editing a tag should be more intuitive. A "..." menu on each tag or simply allowing a double-click to edit would be standard.
• In-App File Renaming: The ability to rename the actual file on disk from within the TagStudio GUI would be a huge workflow improvement.

A Re-evaluation of Sidecar Files

Initially, I was happy to move away from the "sea of sidecar files" that other programs create. However, after considering the limitations of a central binary database, I now believe the sidecar approach (as used by TagSpaces), if done right, is superior for a few key reasons:

• Portability: The metadata (as a .json or .ttl file) lives right next to the source file. If I move the file, the metadata can goes with it.
• Interoperability & VCS-Friendliness: The sidecar is a simple text file, readable by any tool and perfectly suited for version control with Git.

Vision for the Future: The AI-Assisted Organizer

I believe the future of this software category lies in AI integration. The ideal workflow isn't just manual tagging. It's:

1. AI-Assisted Ingestion: I point the software at a folder. It uses local or API-based models to automatically perform OCR, identify entities (people, places, dates), summarize documents, and suggest tags and field data.
2. Automated Knowledge Graphing: It automatically builds the rich RDF-style relationships between all these entities.
3. Visual Exploration: It provides a way to visually navigate this knowledge graph to see connections I never knew existed.
4. Conversational Search (RAG): The ultimate goal would be to "chat with my data." Instead of tag:Legal_Advice AND person:foo_bar, I would ask, "What was Foo Bar's final conclusion on the Baz case?"

Conclusion

TagStudio is built on a fascinating and powerful core idea that correctly identifies the deep-seated problems with modern file management. The developer's passion for solving this problem is clear and commendable.

However, the combination of architectural decisions (single-root library, opaque database) that limit flexibility and interoperability, and—most critically—the non-functional search and poor performance in the current alpha, means I cannot justify investing more time into manually populating it with data. The tool, in its current state, does not solve my problem because it cannot help me find what I've organized.

I will be watching the project's progress with great interest and hope to revisit it in the future when these fundamental issues have been addressed. Thank you for your hard work and for sharing it with the community.

[purpletennisball]

1. The Single-Root Library Model

TagStudio libraries are tied to a single root folder. This is a significant limitation. My files are scattered across multiple folders, e.g., C:\Users...\Documents, D:\Projects, E:\Archive, etc. The ideal system should allow me to add multiple, disparate folders into a single library or "vault," creating a unified view without me having to first reorganize my entire filesystem into one monolithic folder (e.g., Zotero).

A multi folder library feature is already being tracked on #295

2. The Search Function Is Broken

This is the single biggest reason I have to stop my evaluation. The search bar at the top of the application does not work.

• It does not find strings in filenames.
• It does not find tags that have been applied to files.
• It does not find text within the metadata fields I've added.
  A file organization tool whose primary discovery mechanism—search—is non-functional, cannot be used. I had hoped for advanced search features (regex, complex inclusion/exclusion filters), but the complete failure of basic search makes the application's core premise of "rediscovering files" impossible to achieve.

Here is the documentation for Search: https://docs.tagstud.io/library/library_search/. Although I do personally think that the search could be improved in some ways.

Feature Gaps and UX Suggestions

• No Custom Field Types: The application offers a fixed list of fields (Text Line, Text Box, etc.). There is no way to define my own named fields (e.g., a "Case Status" field with a "Dropdown" type).
• Poor Handling of Filesystem Changes: When I rename a file in Windows Explorer, TagStudio simply marks the old entry as "unlinked." It makes no attempt to intelligently notice that a file with a new name but the same hash/size/date might be the renamed file. A more robust system would detect these changes and prompt the user to confirm the relink.
• Tag Manager UX: Editing a tag should be more intuitive. A "..." menu on each tag or simply allowing a double-click to edit would be standard.
• In-App File Renaming: The ability to rename the actual file on disk from within the TagStudio GUI would be a huge workflow improvement.

Totally agree with all of this. IIRC there was a discussion about custom field types in CyanVoxel's discord server and they may be added soon.

P.S. Next time place this in discussions

[Computerdores]

Thank you for your feedback!
Before I go over your points/suggestions in detail, two things:

1. We aren't many that are working on this project. We have one maintainer @CyanVoxel and besides him there are 2-10 core contributors depending on where you stop counting. For that reason I personally tend to react skeptically to suggestions that would require a lot of work on our end to build / maintain. That said we would obviously love to hear them, even if we don't end up implementing them. (Also, implementing it yourself is always quite a convincing argument ^^)
2. I have converted this issue to a discussion since issues are typically meant for specific request or problems.

First, I want to commend the developer on the vision behind TagStudio. The YouTube videos are exceptionally well-made and eloquently explain the shortcomings of traditional file organization. The core concept—moving beyond simple folders and hashtags to a system of rich, relational tags—is exactly what I've been searching for. This review comes from a place of wanting to see this project succeed, but also from a position of honesty about why I cannot continue using it in its current state.

My Motivation: The Search for a "Single Source of Truth"

My digital life is a mess, spread across numerous cloud services (Google Drive/Photos/Keep, OneDrive), local drives, and dozens of external storage devices. Finding anything is a Herculean task.

My journey has included:

* Trying to enforce strict folder and file naming conventions.

* Using powerful command-line search tools like `es.exe` (Everything CLI), which are fast but limited to what's in the filename/path.

* Experimenting with symlinks, which are cumbersome and not portable.

* Trying other tools like TagSpaces (which I abandoned due to its move towards a proprietary model) and the limited tagging in the [Files App](https://github.com/files-community/Files) for Windows.

I was drawn to TagStudio because it promised a solution that didn't rely on sidecar files (initially a plus for me) and offered a powerful, structured metadata system that could exist independently of the filesystem's limitations.

Installation and First Impressions

I installed Alpha 9.5.2 via winget on Windows. The process was smooth, though it didn't create a desktop shortcut, and Windows search struggled to find the app unless I typed the full name. This is a minor packaging/OS quirk.

Just FYI, that is not a supported way of installing TagStudio, as stated in the README.

My first impression of the UI was that it felt unfamiliar. While custom UIs can be powerful, for a utility designed to manage files, a layout that more closely resembles a familiar file explorer paradigm (e.g., a tree view for navigation on the left, items in the center, details on the right) would make initial adoption much more intuitive. The lack of dedicated tutorials exacerbates this; the YouTube videos are great for explaining the "why," but not the "how."

As for the lack of tutorials:

1. TagStudio is still an Alpha as stated in the README, so a lack of such things is to be expected to a certain degree.
2. You can find the existing documentation at docs.tagstud.io (in case it helps you: it is also linked on the repository home here on Github and is typically the first result when searching for "tagstudio" in your search engine of choice)

Core Architectural Concerns

After spending a few hours with the application, I ran into several architectural decisions that conflict with my ideal workflow.

1. The Single-Root Library Model

TagStudio libraries are tied to a single root folder. This is a significant limitation. My files are scattered across multiple folders, e.g., C:\Users\...\Documents, D:\Projects, E:\Archive, etc. The ideal system should allow me to add multiple, disparate folders into a single library or "vault," creating a unified view without me having to first reorganize my entire filesystem into one monolithic folder (e.g., Zotero).

This is planned as per the roadmap. You can find the roadmap in the documentation.

2. The Centralized, Opaque Database

The library is stored in a ts_library.sqlite file. I have two major issues with this approach:

* **It's a "Black Box":** A binary SQLite file is not human-readable or easily manipulated by other tools. More importantly, it is not version-control friendly. I want to be able to track the history of my metadata using Git, which is impossible with a binary database.

* **Location isn't User-Defined:** The database is stored inside the monitored folder. I would prefer the option to store the database file in a separate location (e.g., a synced cloud folder like Dropbox or a private Git repository).

The multiple root directories feature will include this.

My strong preference would be for a system built on open, text-based standards. The semantic web stack offers a perfect model for this:

* **Format:** Turtle (`.ttl`) files are human-readable, highly compressible, and perfect for Git.

* **Model:** The Resource Description Framework (RDF) model of `(subject, predicate, object)` triples is infinitely more expressive than the current system.

* **Schema:** The Web Ontology Language (OWL) would allow for defining incredibly rich relationships between tags and files.

I generally like this idea, however I am somewhat skeptical regarding the implementation, maintenance and performance burden this would introduce. Perhaps create a dedicated feature request if you want to discuss this further as discussing this here would be hard to follow afterwards.

3. Limited Relationship Model

The current parent-tag system implements a simple "is a" or "belongs to" hierarchy (inheritance). This is a good start, but it's a small part of what's needed. An RDF/knowledge graph approach would allow for defining any kind of relationship (predicate). For example:

* `(file:DSC_6645.jpg) (depicts) (person:Foo_Bar)`

* `(person:baz_qux) (author_of) (post:quux)`

* `(case:0123456) (handled_by) (institution:fooo)`

This creates a true knowledge graph, not just a simple taxonomy, which is far more powerful for complex data.

@CyanVoxel can say more on this, but there were reasons that this was decided against afaik

Critical Usability Issues (Showstoppers)

Important

Beyond the architectural disagreements, there are fundamental usability issues in the current alpha that make it non-functional for its primary purpose.

1. Severe Performance Degradation

After importing a large directory, the GUI became extremely slow and sluggish. Every click was met with a noticeable delay, making the application frustrating to use.

Please create a bug report on what you did and what specifically was slow. That way we have a place to track the issue and can ask you for more details as required.

2. The Search Function Is Broken

This is the single biggest reason I have to stop my evaluation. The search bar at the top of the application does not work.

* It does **not** find strings in filenames.

* It does **not** find tags that have been applied to files.

* It does **not** find text within the metadata fields I've added.

A file organization tool whose primary discovery mechanism—search—is non-functional, cannot be used. I had hoped for advanced search features (regex, complex inclusion/exclusion filters), but the complete failure of basic search makes the application's core premise of "rediscovering files" impossible to achieve.

It is not. You can search for filenames (including globs) and tags. Searching field content is planned. Furthermore, all of these things can be combined with complex boolean syntax.

How you can do this is documented at: docs.tagstud.io. Please read the documentation on a feature (and/or ask on the Discord) before claiming that the core functionality of the application doesn't work at all. And if it really does not work as stated, please create a bug report with a description of the concrete thing that is broken so we can fix it.

Also FYI: A UI for the search bar is planned that will make it more intuitive to use than the query syntax in use at the moment.

Feature Gaps and UX Suggestions

* **No Custom Field Types:** The application offers a fixed list of fields (Text Line, Text Box, etc.). There is no way to define my own named fields (e.g., a "Case Status" field with a "Dropdown" type).

* **Poor Handling of Filesystem Changes:** When I rename a file in Windows Explorer, TagStudio simply marks the old entry as "unlinked." It makes no attempt to intelligently notice that a file with a new name but the same hash/size/date might be the renamed file. A more robust system would detect these changes and prompt the user to confirm the relink.

This is indeed a problem at the moment. I believe there is an existing Issue for this you can subscribe to, otherwise you are welcome to open one so you will know when it is fixed.

* **Tag Manager UX:** Editing a tag should be more intuitive. A "..." menu on each tag or simply allowing a double-click to edit would be standard.

Definitely a good suggestion, especially since this is already implemented under the hood and just needs to be enabled.

* **In-App File Renaming:** The ability to rename the actual file on disk from within the TagStudio GUI would be a huge workflow improvement.

A Re-evaluation of Sidecar Files

Initially, I was happy to move away from the "sea of sidecar files" that other programs create. However, after considering the limitations of a central binary database, I now believe the sidecar approach (as used by TagSpaces), if done right, is superior for a few key reasons:

* **Portability:** The metadata (as a `.json` or `.ttl` file) lives right next to the source file. If I move the file, the metadata can goes with it.

* **Interoperability & VCS-Friendliness:** The sidecar is a simple text file, readable by any tool and perfectly suited for version control with Git.

I am skeptical that sidecar files spread around a filesystem are very VCS friendly, as for the text based storage in general, see above.

Vision for the Future: The AI-Assisted Organizer

I believe the future of this software category lies in AI integration. The ideal workflow isn't just manual tagging. It's:

1. **AI-Assisted Ingestion:** I point the software at a folder. It uses local or API-based models to automatically perform OCR, identify entities (people, places, dates), summarize documents, and suggest tags and field data.

2. **Automated Knowledge Graphing:** It automatically builds the rich RDF-style relationships between all these entities.

3. **Visual Exploration:** It provides a way to visually navigate this knowledge graph to see connections I never knew existed.

4. **Conversational Search (RAG):** The ultimate goal would be to "chat with my data." Instead of `tag:Legal_Advice AND person:foo_bar`, I would ask, "What was Foo Bar's final conclusion on the Baz case?"

An API is planned as per the roadmap (you can find it in documentation). Integration for local models is also not something we are opposed to generally.

Conclusion

TagStudio is built on a fascinating and powerful core idea that correctly identifies the deep-seated problems with modern file management. The developer's passion for solving this problem is clear and commendable.

However, the combination of architectural decisions (single-root library, opaque database) that limit flexibility and interoperability, and—most critically—the non-functional search and poor performance in the current alpha, means I cannot justify investing more time into manually populating it with data. The tool, in its current state, does not solve my problem because it cannot help me find what I've organized.

I will be watching the project's progress with great interest and hope to revisit it in the future when these fundamental issues have been addressed. Thank you for your hard work and for sharing it with the community.

PS: I tend to be very direct with what I have to say, please don't mistake that for hostility.

[Qronikarz]

I like to think of TagStudio as not a file browser but a file manager. You can argue that those are synonyms, but I think TagStudio isn't really a substitute for typical file browser. It's a fantastic additional layer that you can use along with your classic file browser. So it's something like a virtual file system.

It seems like you are looking for more typical file browsers just with tags added. You could take a look at Spacedrive, but it is currently abandoned and no word if it will return to development. But from what I remembered it checked few of your concerns - multiple libraries, AI assisted labeling (though it was broken in recent versions). Unfortunately the tags weren't so advanced like in TagStudio.

You can also take a look at my https://github.com/Qronikarz/TagsResearch repo and browse the software list there. Maybe you can find a program that will meet some of your needs and you can later come here and share some nice solutions that could be implemented in TagStudio.

I think the performance problems that you encountered may be because TagStudio has a support for thumbnails of many types of files and at the start it makes them to later use them through cache, but like @Computerdores said, more details are needed.