Using Obsidian Bases to Manage Attachments: A Real Test

Attachments are the part of a vault nobody curates. They accumulate, they’re heavy, and the usual tools for finding things in Obsidian are built around notes.

Bases handles them properly — with one counting surprise that changes how you have to write the filter.

Non-markdown files work, fully

I built a vault with 120 attachments in deliberate proportions — 22 CSVs, 21 PDFs, 28 PNGs, 21 text files, 28 WebPs — so that every number below has a known correct answer.

View	Expected	Returned
file.inFolder("attachments") and not markdown	120	120
file.ext == "png" or file.ext == "webp"	56	56
file.ext == "pdf"	21	21

Exact, every time. No extension type was silently dropped.

file.size works too. This formula produced correct values, and the Sum summary row at the bottom of the table worked:

formulas:
  size_kb: "(file.size / 1024).round(1)"

Which makes the obvious use case viable: sort by size descending, look at the top of the list, reclaim space.

The counting surprise: your .base files are attachments

The natural way to write “everything that isn’t a note” is:

filters:
  'file.ext != "md"'

I expected 120. I got 165.

The extra 45 were the .base files themselves. As far as Bases is concerned, a .base file is an ordinary file in the vault — it has an extension, it has a size, it is not markdown, so it matches.

165 = 120 attachments + 45 .base files

This is mildly funny and genuinely annoying. Your attachment cleanup view fills up with your own query definitions, sorted in among the PDFs.

Write one of these instead:

# by location — best if your attachments live in one folder
filters:
  and:
    - 'file.ext != "md"'
    - file.inFolder("attachments")

# by exclusion — best if attachments are scattered next to their notes
filters:
  and:
    - 'file.ext != "md"'
    - 'file.ext != "base"'

The first is what I’d use. It returned exactly 120.

Re-shot later, after I had added more test bases to the vault: 192 is the same 120 attachments plus 72 .base files. The attachment count never moved — only the base files grew, which is exactly the problem.

The same thing bites elsewhere

This isn’t a quirk of attachment queries. It’s a general property: file.* filters apply to every file in the vault, not just notes.

The place it does real damage is date filtering. A plain “modified in the last 7 days” filter with no extension restriction returned 1,641 on my vault — but only 1,476 of those were notes. The other 165 were the attachments and base files. The count looked plausible; it was over-reporting by more than ten percent.

Nothing errors. The number is simply larger than it should be, which is the hardest kind of wrong to notice.

Set the limit high or the count means nothing

A trap I walked into while building this test: my first version of the “everything non-markdown” view had limit: 50.

It displayed “50 results”.

The count Bases shows is rows displayed after limit, not rows matched. With limit: 50 on a set of 165, the view reports 50 and gives no indication that anything was cut. I only caught it because I had computed 165 beforehand and the number didn’t match.

For a control view — one whose entire job is to tell you the total — the limit must exceed any plausible answer. Mine are at 300 and 2000.

What I could not test

Thumbnail previews. I went back and pointed other layouts at the same 56 images. Here is what 1.13.7 did:

• type: cards exists. It showed a three-column grid of cards, all 56 of them, each with just the file name, no picture.
• type: list exists. It showed a bulleted list of links.
• type: gallery does not exist. It printed Unknown view type: gallery in orange, greyed out Filter and Properties, and still reported 56 results. It doesn’t quietly fall back to a table. A made-up type name does exactly the same thing.

That blank card doesn’t show that cards can’t display images. My views had no image property set up for the cards to use, and Obsidian’s own documentation describes cards as letting you “create gallery-like views with images” (obsidian.md/help/bases/views, checked 2026-09-23). I haven’t tested the configured version, so I’m not going to claim either way.

A starting point

formulas:
  size_kb: "(file.size / 1024).round(1)"
filters:
  and:
    - 'file.ext != "md"'
    - file.inFolder("attachments")
views:
  - type: table
    name: "Attachments by size"
    order: [formula.size_kb, file.name, file.ext]
    summaries:
      formula.size_kb: Sum
    limit: 300

Sort by the size column descending once it’s open. The Sum row tells you what the whole folder costs you, which is usually the number that prompts the cleanup.

---

Tested on the version in the box at the top of this page. Verify against your own install before relying on the specifics.