Give your pages structured fields. A Page Type is one label; properties are named values you attach to pages — a Status of "Active", a Priority of "High", a Due date, an Owner that links to a person page. Define a property once and it's available to every page; fill it in where it's relevant. Properties turn a pile of notes into something you can sort, filter, and reason about.
Properties set on a page show in a small strip just above the page title, each as a name — value chip you edit in place: type into a text or number field, pick a date, toggle a checkbox, choose from a select, or — for a page-link property — click the page to jump to it or the ✎ to point it somewhere else. The ✕ removes a property from the page; ＋ opens the Properties palette to add or manage them.
You keep four hundred sources — PDFs of papers, pages clipped off the web, a shelf of ePubs — and what you want of each of them is the same three answers: who wrote it, what year, and have you read it yet. That is the case properties were built for, and until now it was the one case they could not serve: a page whose body is a document rather than words you typed showed no property strip at all.
It does now. Open a PDF, a saved web page or a book and the strip sits above it exactly as it does above a note — the same fields, edited the same way. Give one a kind and it takes the kind's questions with it, so every paper in a library answers the same three and you can sort and filter the lot of them from a Database View.
They can answer for themselves, too. A property with an instruction reads the document — the paper's actual text, the article inside the saved page, the book's chapters — and fills itself in. Press ✦ Fill on the strip and a stack of sources that arrived with nothing but filenames comes back with authors and years in it.
And a saved web page is searchable. Its words are read out of the snapshot and indexed like any other page's, so searching for a phrase you remember finds the page you kept it on — whether you kept it clean or kept it exactly as it looked. What gets indexed is the article, not the site's menu and footer.
You have four hundred papers and what you want of each is the same three answers: who wrote it, what year, where it appeared. If a page carries a DOI, MojoPad can ask the catalogue that issued it and bring back the published record — no typing, and no guessing.
Open the Properties palette on a page that has one and press ⌕ Look up this source. The button appears only when the page actually carries an identifier, and it names the one it is about to send before you press it.
What comes back is offered, never applied. Each field arrives as a row you accept with ✓ or leave with ×:
That third case is the useful one at scale. Run it down a shelf of references and what you have is a proofreading pass: the handful that disagree with the catalogue, which is not a list anybody can make by hand.
Nothing is overwritten quietly. Where any row would replace something you wrote, Accept all is not offered — those are decisions to take one at a time. A value that came from a catalogue remembers which one and which identifier answered it; type over it and that record is cleared, because from then on the words are yours.
What leaves your Mac is the identifier and nothing else — not the page, not its title, not your notes. See Privacy on the website for exactly what the catalogue learns.
Four hundred references is the size this is for. Select pages in the Pages palette and the bulk bar offers ⌕ Look up… — it appears only when something in the selection actually carries an identifier.
Getting the right pages selected is the other half. A database view can already describe a set nothing else can — carries an Identifier and has no Published in is two filters — and a view now offers ⌖ Select these N, which hands its rows straight to the page list. Describe the shelf, select it, look it up.
A batch fills; it never overwrites. Empty fields are filled in. Anything you have already answered is left exactly as it is and the page is listed at the end — and those pages are left selected, so walking them is already set up. That list is the point: these twelve disagree with the catalogue is a proofreading pass nobody can do by hand.
And a batch fills rather than designs. A field the catalogue knows that your wiki has no property for is counted and skipped, never created — adding a property changes every page in the document, which is not a thing to do four hundred times from one dialog. Look that source up on its own page to add it.
Protected pages are skipped and said so. Nothing stops the run: a source with no record, or one that could not be reached, is counted and the rest carry on, and the report at the end says how many of each.
A property that answers its own question comes back with paragraphs, not a label — a summary, an argument, the objections somebody might raise. At the top of a page that is a lot of room for one field, so a long value shows its first few lines and fades out; click into it and the whole thing opens, and you can drag the corner of any one value to size it by hand.
How many lines is yours to set, in Settings ▸ Editing ▸ Long property values — three, five, ten, or Show all of it, which never fades one. Pick that last if you put a summary at the top of a page in order to read it rather than to know it is there.
You keep a Summary and an Author at the top of every paper you read, and you read them as much as you read the page underneath. By default the strip is drawn smaller and quieter than your writing, because on most pages it is a label rather than the point. When it is the point, three settings move it — all in Settings ▸ Editing ▸ Properties.
Property text size sends the strip to the same size as your page text, a step under it, or a step over it. The three choices that mention the page follow it, so if you change your page text later the strip comes with it rather than being left behind at a size you set once and forgot. Property text colour keeps the strip in the page’s own ink or drops it a shade for a quieter top-of-page. Behind each property chooses the soft band each one sits on, a stronger one to tell them apart at a glance, or none at all for a strip that reads as a single line of small print.
Size and zoom are different things. Zooming a page carries everything with it, including the strip — the whole page simply gets bigger. These three change the strip relative to the writing, which is what you want when the properties matter more, or less, than the words below them. Everything stays in whichever theme you are using, so the strip is still part of the page rather than something sitting on top of it.
Ask for five lines and you get five lines. If you turn the strip up, the number of lines a long value shows — the setting just above — still means what it says, at the new size.
Seven types, and the seventh is the odd one. Beside Text, Number, Date, Checkbox, Select, and Page there is Note (formatted), which holds markup rather than a value — paragraphs, lists and emphasis, kept as written instead of flattened onto one line. It is the right choice for a Summary or an Abstract, which are part of what the document says rather than a label on top of it. See A property that holds prose under AI Agents.
Open the Properties palette (the strip's ＋, or click any property name). + Add property takes a name and a type:
Definitions live in the document, so they travel with it. Values are stored on each page and are encrypted along with the page when you lock it — see Encryption and Privacy.
You have just clipped a paper and you can tell there is structure in it, but you would have to invent the whole scheme before you could capture any of it. That is the wall this is for. On a document with no properties defined, the Properties palette offers ✦ Suggest properties: it reads the page and comes back with the two or three it actually states — an Author it found in the byline, a Published date, an Identifier that is really a DOI.
Each row shows the name, what kind of field it would be, and the value it found. Accepting one does two things: it adds that property to the wiki, so every page can use it from then on, and it fills it in on this page. Skip the ones you don't want — nothing is created until you say so.
Why the names look generic. The suggestions are drawn from a short list of the words catalogues and libraries have long since settled on — Author, Publisher, Published, Subject, Source, Identifier, Rights and a few more. It is tempting to want Writer on one page and By on the next, and that costs nothing until the day you want every book in your wiki sorted by who wrote it and discover there are three different fields holding the same fact. Starting from the common word means your wiki can be sorted, grouped into a Database View, and exported to anything else that reads them. If a name doesn't suit you, rename it afterwards — click the property in the strip and change it, and every page follows.
It will only ever offer a name from that list. Ask it about a page it can find no structure in and it says so rather than inventing something.
Beside by hand and by the model, a property can be answered by a server you connect — hand it an identifier, an address or a ticker and let the thing you connected turn that into the value. Or, when what you have is a question rather than an identifier, pick ✦ Let AI choose the tool and write the question instead: a model reads the page, decides which of that server's tools answers it, and runs it. Both are set up in the Properties palette; the details, including the two permissions the second one needs, are under Letting something else answer a property in AI Agents.
Ask for the five most recent headlines on that site, or the papers this one cites, or three suppliers who make this part, and what comes back is not a paragraph — it is a set of things that each have a name and a line about them. MojoPad draws that as a wall of cards: one card per item, with its section or source in small capitals at the top, the name of the thing, a sentence or two, and — when the answer came with a real address — a Read more button that opens it.
You do not ask for cards. Write the question the way you would say it out loud. MojoPad asks the model to lay a set of things out — in the same words whichever way the property is answered — and when the model replies with a plain list instead, MojoPad draws the wall itself. So you get the layout from a model on this Mac and from a provider alike, without ever having asked for it.
It leaves everything else alone, on purpose. A sentence, an explanation, two items, a name with a bare figure beside it, a list with anything nested underneath it, or a list that is not the last thing in the answer all stay exactly as they were written. Rearranging what a model wrote is worth doing only when the shape is unmistakable, so the bar for it is set high — if an answer you expected as cards came back as a list, adding a sentence of detail to each item is usually what tips it.
A numbered answer keeps its numbers. Ask for steps in order and each card carries its number, so a sequence still reads as a sequence rather than as a heap of boxes.
The look is MojoPad's. The cards take their colours from the theme you are in, so an answer written on a light morning still looks right at night, and a wall you collected last month matches the one you collected today. They also travel: see Exporting for what happens when you send one to somebody who does not have MojoPad.
Once your document has properties of its own, the button becomes ✦ Fill with AI and its job changes: it reads the page and suggests values for the properties you defined — a Status it infers from the wording, a date it spots, the right Select option. It stops proposing new names at that point, because the names are yours; it will never rename or replace one you chose.
Either way you review each suggestion and accept the ones you want, nothing is written automatically, it runs on your local model (see Local AI), and it won't invent a Select option or link to a page that doesn't exist.
Properties are a lens on your whole wiki. In the Properties palette, ⊞ Collect by property… (or the ⊞ beside any value) filters the page list to every page sharing that value — "show me all the Active projects". A chip at the top of the list shows the filter and the count; ✕ clears it. Found a filter you'll want again? Click the ☆ on that chip to save it as a smart folder — a saved query that lives in the folder tree as a ◎ row with a live count. Click it any time to re-run the filter against your pages as they are now. See Navigating.
Open the Graph (⌃⌘G) and the Lens… menu gains your properties. Pick a value to
spotlight the matching pages, or choose ◑ Colour by a property to paint every node by
its value, with a colour key in the corner — your map, read by Status or Priority at a glance. See
The Graph.
Put the caret on a picture or a table and choose Format ▸ Caption This Picture or Table (or type /caption). The caption appears with its number already on it — Figure 1., Table 1. — and the placeholder wording is selected, so you just type over it.
The number is never stored, only worked out. Add a figure halfway down a long piece and everything below it renumbers on the spot: no command to run, nothing to remember, and no way for a draft to reach print saying Figure 2 twice. Figures and tables count separately, so a table between two pictures does not disturb them.
They travel as captions, not as a paragraph in italics — out to the web, to a PDF, and into Markdown, where the number is written in for you because a plain text file has nothing to count with.
Type /cite (or Format ▸ Cite a Source…) and pick a source — your references come first in the list, each showing how it will read. The citation goes in as (Lovelace & Babbage, 1843).
The words are not in your page. A citation remembers which source, and reads itself from that source every time the page is drawn. So correcting a misspelled name once fixes every citation of it in the whole document, and fixing a year fixes it everywhere — including in reference lists, without opening a single page that cites it. That is the thing a word processor cannot do for you.
/references drops in a list of what this page cites, in the order you cited them. Cite something new and it joins; delete your last citation of a source and it leaves. Nobody maintains it, so it can never drift out of step with what you actually wrote — which is the only way a reference list ever goes wrong.
It lists what a source is — who, when, what it was called, where it appeared. It is deliberately not an APA or MLA engine: getting a named style exactly right is a lifetime of edge cases, your reference manager already does it properly, and a list that is almost right in a named style is worse than an honest one in no style, because it looks finished.
It reads whichever field you happen to use. A source's author can sit in Authors or Author; its year in Year, or in a Published date it takes the year from; where it appeared in Published in, Journal, Publisher or Source. You do not have to know which of those a bibliography import made and which you typed yourself — each source is read from whichever of them it actually answers, so a wiki that grew both ways still cites correctly.
/refer to a figure writes Figure 3 into your sentence — and keeps it true. Add a picture above it next week and the sentence says Figure 4, because the reference remembers which figure, never which number. If the figure is deleted it says so plainly rather than leaving a number that now points at something else.
Properties round-trip through YAML frontmatter. Export a Markdown Page and its properties ride
along at the top between --- fences; import a Markdown file that carries frontmatter and
MojoPad creates the properties (inferring each type) and fills the values. So your structured fields
survive a trip through Obsidian, a static site, or a plain-text backup.
A paper has three authors. A note is about four things at once. A recipe came from two books. When you make a property, you can say it holds several answers instead of one — and the choice you make next matters more than it looks:
Each answer shows as its own small chip you can take off with ✕, and you add one by typing and pressing Return. Nobody ever sees how they are stored.
They come into their own in a database view. Group a view by a several-answer property and a page appears under every answer it holds — three papers that all touch computation all show under it, and each also shows under its own other subjects. That is the thing a comma-separated text field can never do, and the reason to reach for this instead of typing them into one box.
Exported Markdown carries them as a proper YAML list, so a page with three authors leaves here still having three. Reading one back in works too: a YAML list in a Markdown file becomes a property holding many answers, so a round trip through MojoPad's own export and import gives back what left. (A list arriving from another app becomes a text property with many answers rather than a typed one.)
If you keep setting the same properties on the same shape of page — every interview, every recipe, every book — say so once instead. See Page Kinds.