Upgrade Storage"Title" field in Attachment Info should be "Format" (or similar)
Filenames are (supposed to be) unique identifiers, so separating them from a title makes sense.
That said, labeling the field that stores the file format (e.g., PDF, HTML) as "Title" drives me batty for a couple of reasons.
First, titles are descriptive names for things. "Canterbury Tales" is a title. PDF and HTML are file formats, not descriptive titles. Calling a file’s format its "Title" is simply incorrect terminology.
Second, it’s inconsistent with how "Title" is used elsewhere in Zotero. In the parent metadata, the "Title" field refers to the actual name of the work—what most people understand as a title. That same descriptive title appears in the "Title" column in the library view. As far as I can tell, this is the only place in Zotero where "Title" is used to mean something entirely different—not a title at all.
Looking at the Attachment Info section:
| Label | Data Stored |
| -------- | --------------------|
| Title | File Format |
| Filename | Filename.extension |
| Modified | Date and time modified |
| Indexed | Yes/No |
This section is clearly focused on information about the file itself. Given that, and the fact that this particular field is storing the file format—not a title—it would make much more sense to relabel it as "Format" or "File Type". That would align with both the actual data being stored and the surrounding context.
Bonus: We'd probably see less confusion around why that field doesn't contain a title.
(Cataloging Librarian who configures the catalog user display, which has nothing to do with Zotero but everything to do with my being batty. No banana for scale because I ate it for breakfast).
That said, labeling the field that stores the file format (e.g., PDF, HTML) as "Title" drives me batty for a couple of reasons.
First, titles are descriptive names for things. "Canterbury Tales" is a title. PDF and HTML are file formats, not descriptive titles. Calling a file’s format its "Title" is simply incorrect terminology.
Second, it’s inconsistent with how "Title" is used elsewhere in Zotero. In the parent metadata, the "Title" field refers to the actual name of the work—what most people understand as a title. That same descriptive title appears in the "Title" column in the library view. As far as I can tell, this is the only place in Zotero where "Title" is used to mean something entirely different—not a title at all.
Looking at the Attachment Info section:
| Label | Data Stored |
| -------- | --------------------|
| Title | File Format |
| Filename | Filename.extension |
| Modified | Date and time modified |
| Indexed | Yes/No |
This section is clearly focused on information about the file itself. Given that, and the fact that this particular field is storing the file format—not a title—it would make much more sense to relabel it as "Format" or "File Type". That would align with both the actual data being stored and the surrounding context.
Bonus: We'd probably see less confusion around why that field doesn't contain a title.
(Cataloging Librarian who configures the catalog user display, which has nothing to do with Zotero but everything to do with my being batty. No banana for scale because I ate it for breakfast).
This is a hierarchical tree, so child items exist in the context of their parent items. That's why repeating the parent metadata is redundant and why "PDF" is a perfectly descriptive title for the primary PDF file attached to the item.
I understand that the “Title” field is the editable name of the attachment and that Zotero defaults it based on the file format (like “PDF” for .pdf files). I didn’t mean to criticize the internal data model, nor do I think it’s flawed. My phrasing—especially saying the field “stores the file format”—was literally incorrect from a data model perspective, and I appreciate your clarification. You’re right—I misspoke.
That said, from a user perspective, there’s a real disconnect.
Previously, the Title field often matched the Filename. This was unintentional and has since been fixed.
Now, there’s noticeable confusion. Seeing “Title” paired with values like “PDF,” “HTML,” or “Snapshot” clashes with users’ expectations of a title as a descriptive, unique name—not a generic file type.
The issue isn’t the data model—it’s the user interface label. Labels give data meaning and shape expectations. Without the right display label, even well-structured data can be misunderstood or ignored.
I think the user-facing label could be revisited and clarified to better match user expectations and reduce confusion, without changing the underlying model. Even a simple tooltip or note in the interface explaining the field’s intent could help reduce confused threads/support tickets/etc.
Thanks again for the clarification, and sorry for any unintentional disconnect. Does that clarify where I’m coming from?
We're still working on additional changes here that we hope will further clarify the difference and address complaints from people who just really prefer seeing filenames in the items list for whatever reason, but "Title" really is the appropriate term.