Skip to content
Open beta — everything’s free right now, and your rate is locked when it ends.

Searching a table from the view bar

Click the magnifier, type, and the grid narrows as you type — case-insensitively, across the text fields, on the server. What search covers, what wants a filter instead, and how the two compose.

Updated August 2026

The magnifier sits at the right end of the view bar. Click it and it expands into an input; type, and the view narrows as you type — the query runs on the server, so it searches the whole table, not only the rows your browser happens to have loaded.

The view bar search expanded on the Orders table with "van" typed — the grid narrowed to the one matching order.

  • Keystrokes are debounced for a quarter second, so the grid follows your typing without a request per letter.
  • Escape clears the search and collapses the box. The small × clears it but keeps you in the box for the next query.
  • The record count at the bottom updates live, so "how many mention this" is answered without counting.

What it searches

Search matches the text-family fields: single-line text, long text, email, phone and URL fields — and formulas that produce text. Case-insensitive, Arabic included, and a literal % or _ is a character, not a wildcard.

What it deliberately doesn't match: numbers, dates, checkboxes, selects, members, link chips, attachments, lookups and rollups. Those are structured values, and structured questions get exact answers from filtersStatus is New beats hoping the word "new" appears nowhere else. If you keep searching for the same select value, that's a saved view with a filter wanting to exist.

It composes with the view

Search doesn't replace the view's filter — it narrows within it. On a view filtered to unpaid orders, searching van finds the unpaid orders that mention a van, not every order that does. The Filter panel shows both numbers while you have a search on — matching records out of the searched total — so you can see what each layer is contributing.

The same one search applies across the table's views: switch from the grid to the board or the calendar and the search term rides along, composing with each view's own filters.

The column summaries follow too. They compute over the records currently matching, so searching ribbon on an orders table turns the Total column's sum into "the value of orders mentioning ribbon" — a question answered without building anything.

It's yours, and it's temporary

A search is session state, not view configuration. It isn't saved into the view and teammates never see it. Reload the page or switch to another table and the box is empty again. Filters are the durable version of the same idea — that's the split: search for the question you're asking right now, filter for the question the view always answers.

The questions people ask

Why doesn't searching a customer's name find their orders? The customer's name is text on the Customers table; on Orders it's a link chip, and chips aren't text. Search the Customers table, or filter Orders by the link. (A lookup is also a lookup — search skips those too, since their text lives elsewhere.)

Does it search fields the view hides? Yes. Hiding a field is a display setting (hiding fields); the search runs against the table, so a match in a hidden field still surfaces the row. If a result looks inexplicable, that's usually why.

Is there search on a shared view? No — a public view link shows the view exactly as you shared it, with no search box. What you share is what they see.

Tabla is the database we build these on.

A no-code database with real Postgres underneath: every feature on every plan, a million records per database, and your whole database back out in one file, any day.

More guides