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

The single line text field

Plain text on one line: what it stores, the require-unique option, how it edits, filters, and sorts, what the API returns — and when long text is the better call.

Updated August 2026

The plainest field there is: text, one line of it. Names, order codes, SKUs, cities, titles — anything short enough to read whole in a cell. Both example tables in this guide come from a small plant shop's database, where Name on the Plants table is a single line text field holding "Monstera deliciosa".

It stores exactly what you type. No trimming, no casing, no interpretation — the one exception is line breaks, which a single-line field can't hold: a newline pasted or typed into the cell is collapsed to a space.

Adding a single line text field: the type selected in the picker, with the Require unique values toggle in the settings pane.

Create it

Click + at the end of the grid header (or a column header → Insert right), and Single line text is already selected — it's the default type. One option:

  • Require unique values — no two records may share this value, enforced by the database itself, not by a warning. It can only be switched on when the field is created. Writing a duplicate is refused with the value named: "SKU" must be unique — "A-1" already exists. The details are at Require unique values.

Editing

Click a cell and type — typing replaces the value, Enter commits and moves down, Escape cancels. In the record panel it's an ordinary text box. At the Short and Medium row heights the grid shows one line and truncates the rest; at Tall and Extra tall, long values wrap.

Text fields are covered by search, and this type can be the table's display field — the first field of a new table usually is.

Filtering and sorting

The operators: is, is not, contains, doesn't contain, is empty, isn't empty. contains is case-insensitive. Sorting is alphabetical; ascending puts empty cells last.

One honest wrinkle: an empty text cell can be stored as nothing at all or as an empty string, depending on how it was cleared. You will never see the difference — is empty catches both, and both read as blank.

Over the API

A text cell is a JSON string:

{ "fields": { "Name": "Monstera deliciosa" } }

Write it with a string; clear it with null. A number sent to a text field is refused with Field "Name" expects text. — the API doesn't guess. Reading an empty cell returns null or "" (see the wrinkle above); treat the two the same, as Tabla's own filters do. The whole write grammar is at Writing records over the API.

When long text is the better call

Reach for long text when the value is prose: notes, descriptions, anything you'd write in sentences. Long text holds line breaks, wraps in the grid a row height earlier, and can turn on rich formatting. Since the two share the same storage, converting between them later is free in both directions — nothing is truncated either way.

And two cases where text is the wrong family entirely: numbers you'll sum or compare belong in a number field (text sorts 10 before 9), while emails, phone numbers, and URLs have their own types that keep the value clickable. Phone numbers in particular are not numbers — a number field would eat the leading zero.

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