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 them all 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 an identifier, MojoPad can ask the catalog that answers for it and bring back the published record — no typing, and no guessing.
Three kinds of identifier, three catalogs. A DOI is settled by Crossref, a PubMed number by PubMed, an ISBN by Open Library. You do not choose — the shape of the identifier decides. A page carrying more than one is asked of Crossref, which is the registry of record for the fields they share.
A paper has three names, and looked up once a page learns all of them. Its DOI, its PubMed number and its PubMed Central number each land in a property of their own — filled whenever a catalog states them, and left empty when none does, because plenty of papers are not in PubMed and plenty more are not in PubMed Central. The three properties are added to your wiki the first time a lookup runs; you define nothing.
A page found by its PubMed number gets all three from that one record. A page that knows only its DOI is asked of PubMed for the other two, and the button says so before you press it. That answer is only believed when PubMed returns exactly one record and that record's own DOI is the one on your page — because asking PubMed by DOI is a search rather than a lookup, and a search that answered with a near miss would put another paper's number on your page and start opening it from your citations.
Each of the three also becomes an alias. That is what makes writing
PMID32766779 in a note into a link, and what makes a citation written as a doi.org
address, a PubMed address or a PubMed Central address open your copy of the paper. A learned name
is only ever added — never removed, and never taken if another page already answers to
it. To take one off, use the alias box at the foot of the Properties palette, where all your
aliases live.
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 catalog, 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 catalog 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. That is true of the PubMed step as well: what is sent is the DOI already on your page. See Privacy on the website for exactly what the catalog 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.
Or ask which papers are short a number. The Properties palette offers ⌕ Papers missing a number… whenever any stored paper is missing its DOI or its PubMed number. One press selects every one of them; ⌕ Look up… is the next. Nothing is sent until you agree to the dialog that names the catalogs.
Why it does not ask for the third. PubMed Central holds what is free to read, so a paywalled article — and every paper outside medicine — has no PubMed Central number and never will. Treating a missing one as work still to do would mean this control selected your whole library forever, and every run asked the catalogs the same settled questions about every paper on it. Two names is the answer; the third lands whenever it exists.
What it costs, said plainly. Up to four requests for a page that already prints its number: one to settle the identifier, two to ask PubMed which record that number belongs to and then read that record back, and one for its citation count. Three when the catalog that answers the citation count has already named the PubMed number, so the search can be skipped. A page found by its title costs one more before any of those; a page found by its name costs up to four more, and up to nine in all. A shelf of thousands is an overnight run. You can stop it at any point, and a page that already carries its DOI and its PubMed number is skipped the second time without a single request.
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 catalog is a proofreading pass nobody can do by hand.
A field that holds several identifiers only grows. A set holding an ISBN you typed in by hand keeps it and gains the PubMed number a catalog just stated — that is new information rather than a disagreement, so it is added rather than reported. And the three identifier properties are an exception to a batch fills rather than designs: DOI, PMID and PMCID are MojoPad's own vocabulary, like Title, so a wiki that has none is given them. The dialog says so before you agree.
The summary at the end counts the new answers separately: how many pages learned another name for the same paper, how many were identified by their file name, how many drafts a connected assistant had recorded were confirmed by a catalog, how many drafts are still unconfirmed because the catalog was only ever asked about the drafted number itself, and how many already carried a DOI and a PubMed number and were skipped.
And a batch fills rather than designs. A field the catalog 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, one that could not be reached, and one the catalog was too busy to answer are each counted separately and the rest carry on. The distinction matters at four hundred — no record says the identifier is wrong, too busy says to run it again in a few minutes.
The way an answer fails that looks most like success is a reference that does not exist. Ask for twelve and you get twelve — formatted, plausible, and some of them possibly invented. The moment you are least likely to check is the moment you are about to paste the table into something.
Under any answer that names a DOI, a PubMed number or an ISBN, MojoPad offers ⌕ Check citations. It asks the catalog that settles each one and then says, in a sentence, what it found — and it names the ones that did not resolve rather than reporting a score. "Eleven of twelve verified" leaves the twelfth for you to find by hand, which is the whole problem over again.
A catalog that could not be asked is not a fabrication. A busy or unreachable service is counted and said separately, because reporting one as an invented citation would teach you to distrust a real source.
The sentence stays with the answer. Reopen the conversation next month and you see what the catalogs said that day, not what they would say now — a check is a thing that happened, and quietly re-running it would replace a record with an opinion.
Checking is separate from ⊕ Add sources on purpose: deciding whether to trust an answer comes before deciding to keep it, and finding out whether twelve references are real should not require making twelve pages.
Two things this solves, both of them for somebody with a large library. You want to write PMID12345678 in a note and have it open the paper — your copy if you have one, the registry if you do not, and without ever going back to change what you wrote once the PDF arrives. And you want a program of your own that fetches papers to be able to drop a file into a folder and have MojoPad recognize it as the work you have been citing all along.
Both need one thing: a name that cannot drift. A title is the obvious choice and the wrong one. Titles carry colons and non-English characters, the same author publishes twice in a year, et al. is never abbreviated the same way twice, and a retraction notice gets appended to the title after you filed it. An identifier is issued once and never changes.
So the rule is: name the file after the identifier, and the page is named after the file.
| Kind | The file you save | The page MojoPad makes |
|---|---|---|
| PubMed | PMID12345678.pdf | PMID12345678 |
| PubMed Central | PMC1234567.pdf | PMC1234567 |
| DOI | doi-10.1038%2Fnature12373.pdf | doi-10.1038%2Fnature12373 |
Keep the letters on. They are not decoration. A PubMed Central number and a PubMed
number are both runs of digits and they overlap — take PMC off
PMC12360398 and what is left is a valid PubMed number belonging to a
different, real paper, which a lookup would find and a citation check would then mark as
good. A wrong citation with a check beside it is the worst thing this app can hand you.
And a bare run of digits is never treated as a citation, anywhere. In medical and legal writing a number is a case number, a docket number or a record number far more often than it is a PubMed id, and a rule that claimed them all would put a link on every number you wrote. The one exception is a field named for a kind of number: bare digits in PMID are a PubMed number and bare digits in PMCID are a PubMed Central one, because the field name says which. In Identifier, in Year or anywhere else, a bare number claims nothing.
The name is not the only thing that names a paper any more. A page is the paper it says it is: by its name, by any of its aliases, and by the DOI, PMID and PMCID properties a lookup filled in. A citation written any of those ways opens your copy. So you can leave every page called whatever the file was called — the name is free, and the lists show the Title anyway.
Two things are deliberately excluded from that. A value a connected assistant recorded is a draft, marked as one, and does not decide anything until a catalog confirms it. And a protected page still answers to its name — a click on a citation offers to unlock it — but never to what is inside it.
When two pages answer to the same paper — the PDF, and a report that files the same DOI in a column — the citation opens the one that is most plainly the paper. A page named for it beats one that is only aliased to it, and either beats one that merely holds the number in a field; where the claims are equally direct, the page holding the document beats one that only writes about it. And where even that is a tie — two notes each keeping the same DOI in a column — one of them is picked in a way that has nothing to do with your ordering and comes out the same on every machine that opens the wiki. That last choice is arbitrary: it is there so a citation cannot open one page on your laptop and another on your desktop, not because either page deserved it. Help ▸ Diagnostics counts how many identifiers two pages both answer to, so you can find them and settle them yourself.
A reference manager, or a browser's Copy link to highlight, writes an address that
carries not just the paper but the exact words you meant — a text fragment,
written #:~:text=… at the end of the address. Sent to a browser it opens the
page scrolled to that sentence with it marked.
MojoPad opens your copy of a paper when the wiki has one, which is right and used to lose the sentence: you arrived at a hundred-page PDF with nothing to say which line the link was about. Now the passage is found in your PDF and highlighted, and you are taken to it. The highlight is a real one and stays; click the same citation again and MojoPad goes to the mark already there rather than making a second.
The match ignores everything but letters and digits, on purpose. A published PDF breaks words across lines with a hyphen and drops the space at the break — “organisms (MDROs)” can sit across two lines and read as one run of characters — so any comparison that respects spaces and punctuation fails on exactly the long quotes people cite.
If the words are not in your copy, MojoPad says so rather than doing nothing. A fragment is written against a web page, and a publisher's PDF is not always the same text as the web version of the same article; when that happens the find bar opens on the quote so you can look for it yourself.
A DOI cannot be a filename as it stands. Its specification says every DOI is a prefix and a suffix separated by a forward slash — and a forward slash cannot appear in a filename on macOS, Windows or Linux. That is not a rule anyone chose; it is what a slash means to a filesystem. Swapping it for an underscore does not work either, because real DOIs already contain underscores and nothing afterwards could tell which was which.
So the awkward characters are percent-encoded, which is not a MojoPad invention: the DOI Handbook already defines this encoding for carrying a DOI somewhere that cannot hold its characters, and recommends it for a suffix containing a slash.
The rule, in words. Take the DOI with no web address and no doi: in front.
Lower-case it. Encode every character that is not a letter, a digit, or one of
. _ - ~, using a percent sign and two capital
hexadecimal digits. If the result ends in a period, encode that too — Windows silently removes a
trailing period from a filename, so a DOI ending in one would come back as a different name with
no error at all. Then put doi- in front.
Encoding, in Python:
from urllib.parse import quote
def doi_to_name(doi):
s = quote(doi.strip().lower(), safe='._-~')
if s.endswith('.'):
s = s[:-1] + '%2E'
return 'doi-' + s
# 10.1038/nature12373 -> doi-10.1038%2Fnature12373
And back again:
from urllib.parse import unquote
def name_to_doi(name):
if not name.startswith('doi-'):
return None
return unquote(name[4:])
In JavaScript:
const doiToName = (doi) =>
'doi-' + encodeURIComponent(doi.trim().toLowerCase())
.replace(/[!'()*]/g, (c) => '%' + c.charCodeAt(0).toString(16).toUpperCase())
.replace(/\.$/, '%2E')
const nameToDoi = (name) =>
name.startsWith('doi-') ? decodeURIComponent(name.slice(4)) : null
Or do not write it at all. If your program can reach MojoPad's connector, ask it instead: the read_identifier tool takes an identifier written any way — bare, labeled, as a web address, or as one of these filenames — and answers with the key, the name to save the file under, and the address it stands for. One authority beats two copies of a rule that can drift apart.
Two things your program must not do. Always write the extension: MojoPad names the page by removing the last dot-segment, and a DOI is full of dots, so a file with no extension loses part of its identifier. And never rename a paper after saving it — a renamed file arrives as a second page rather than as the same one.
A page called doi-10.1038%2Fnature12373 tells you nothing, which would be a poor
trade for all of the above. So the work's title lives in a property, and the lists show the
property. Look a paper up and the Title field fills from the catalog; from then on the
sidebar, search, the page picker, the backlinks panel and the graph all show the title, with the
identifier a hover away. Nothing is renamed and nothing is written into your pages — the name
stays the key, so every link you have made keeps working.
This only happens for pages named by an identifier or by the file they hold. A page you named yourself always shows the name you gave it, whatever properties it carries.
Nothing is ever renamed, and there is no "name these by their titles". Once a page carries its three numbers, its name has no work left to do — a citation finds the page through the numbers rather than through what it is called — so leaving four thousand file names exactly as they are costs nothing. Renaming one by hand keeps the old name as an alias, so that stays safe too.
Help ▸ Diagnostics counts this for each wiki: how many pages carry all three names, how many know only one, how many are named like a DOI written with underscores and carry no number yet, and any identifier two pages both claim — which is worth knowing, because only one of the two can win a click, and it does so in silence.
Give your papers a Kind with Title first among its shown properties and every paper page opens with its title on the first line as well.
When the PDF arrives, it arrives by itself. Once you have read a library folder, MojoPad watches it. A paper your own program drops in there turns up as a page without you going back to the menu — and if you had already made a page for it, a stub named for the identifier, the file joins that page. Every mention you have already written starts opening your copy instead of the web, with nothing rewritten and nothing to re-run.
If that page has your own writing on it, MojoPad leaves it completely alone and says which ones it skipped. A file page holds a file instead of words, not as well as them, so filing the PDF on top would take your notes with it — and losing a page of your own writing to something that happened in the background is not a trade this app gets to make on your behalf.
A page that only mentions the paper is a different matter. A note you wrote about the work, or a source page landed by ⊕ Add sources, keeps the paper's DOI in a property — but it is a page about the paper rather than the paper itself. So the PDF is filed as its own page beside it, and the note is untouched. A page whose name or whose alias is the identifier is the stub the file was waiting for; a page that claims the paper only through a property is one too, but only while it is still empty — once you have written on it, it is a note about the paper and the PDF goes beside it.
Watching adds nothing to what MojoPad may read. It notices that a granted folder changed and asks itself to look again, through the same door as the menu item — so a folder you never granted is still refused, and a wiki with a password is still refused. A paper that arrives this way is marked as having come from outside, exactly as one read from the menu is, which is what stops anything in it running. And nothing interrupts you: what happened goes in the status line, not a dialog. If you would rather it did not watch at all, File ▸ Stop Reading a Library… gives the folder back.
If it goes wrong, the diagnostics report (Help ▸ Copy Diagnostics) lists how many pages carry a recognizable identifier, how many of those have their Title filled, and how many papers in a library folder joined an existing page rather than making a new one — which is usually enough to see whether the names on disk match what MojoPad is looking for.
If you keep references in Zotero, MojoPad asks it before it asks anybody else. It is the best of the five places it can look: it is on this Mac, so it costs nothing, needs no key, and has no allowance to run out — and unlike a public catalog it knows what you decided about a work. The tags you filed it under come across as Keywords, which is the one thing no registry in the world can tell you.
Where a catalog and your library both know a field, the catalog wins — a registry of record is the better authority on how a journal spells its own name. Where only your library knows something, nothing competes with it. Each value is marked with whichever of them answered, so a page can always say who said so.
Nothing is sent anywhere for this. MojoPad reads the copy of the library already on this computer, over an address that never leaves it, and only ever reads — it does not add to your library or change it. Zotero has to be running, with Allow other applications on this computer to communicate with Zotero switched on in its Settings ▸ Advanced. Settings ▸ Sources has a Check the connection button that says which of those is missing rather than simply failing.
If you do not use Zotero, none of this appears and nothing about looking a source up changes.
Knowing what a paper is does not tell you whether to read it. The three catalogs above answer the first question. A fourth, Semantic Scholar, answers the second: how often the work has been cited, and whether there is a copy anybody can read. MojoPad asks it alongside the others every time you look a source up, and its answers arrive as ordinary rows you accept or leave.
Deciding which of four hundred sources to open first is the job this is for. A shelf looked up in bulk comes back with citation counts on it, and a database view can then sort by that column — a reading order you could not otherwise produce without opening every one.
It is asked by DOI, so a book has none, and a paper cited by its PubMed number is asked about using the DOI its PubMed record supplied. When the fourth catalog has nothing to say the first three still answer: you lose the count, not the lookup.
Without a key the count often does not arrive. Everyone who has not asked for a key shares one allowance, and it is usually spent. A key of your own is free, by request, and goes in Settings ▸ Sources. It does not make a lookup faster — the pace is the one the service asks for either way — it gives you an allowance nobody else is spending.
Your key does not live in the settings file. It is encrypted by macOS and kept in a file of its own, so it is not carried along when settings are copied to another Mac or sent to support, and it is never shown again once saved. If the catalog refuses it, MojoPad says so plainly rather than blaming your connection — clear the box to carry on without one.
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 color 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 made a Summary property months ago, filled it in on two hundred pages, and only later started asking AI to write those summaries — and now they arrive a paragraph long, sometimes with a list in them, in a field built for a single line. Or the reverse: you made something a note to be safe, and it turns out to hold nothing but a name, so the drawn box is wasted height on every page. Either way the type you picked at the start is no longer the type you want.
Open the Properties palette and click the property's name. The panel that opens tells you which of the two it currently is — Edit “Summary” · text — and under the name box there is a line saying what the other one does, with the button to switch: ⊞ Make it a note, or ⊞ Make it ordinary text if it is a note already. Every page that has an answer is converted in the same pass, and an Undo sits beside the confirmation.
Two properties do not offer it. A property that holds several values at once has no single answer to convert, and one that is a number, a date, a checkbox, a select or a page link is not one of the two kinds this switches between — so on those the line simply is not there. Pages you have locked with a password are left alone as well: what a password covers is not MojoPad's to convert, and the confirmation says how many were skipped.
Text and note, and nothing else. A property of words cannot be turned into one that holds a number or a date, and that is deliberate rather than unfinished: “$1,200” would become 1, and “1965” a day in January you never wrote. Inventing a value nobody typed is not something to put behind an are you sure.
If your answers already have formatting in them, you will be asked a question. An answer that arrived from AI, from a clipped page, or from a connected tool may carry formatting instructions rather than being plain words — and nothing can tell, from the answer alone, whether you meant the formatting or meant to write about it. So MojoPad shows you one of your own answers rendered both ways and asks which you meant:
Showing them as formatting is the one direction that does not simply reverse. The answer is then real formatting, and a note holding real formatting cannot be flattened back into a single line without losing it. The Undo beside the confirmation is the way back, so look at the result before you move on — and if you have two properties to convert, do one, check it, then do the other.
When it refuses. Turning a note back into ordinary text stops and changes nothing if any page's answer holds something plain text cannot keep — styling, a picture, a table or a link. The message says how many pages are involved, though not which ones. Nothing is half-converted: either every page changes or none does, so a refusal never leaves the wiki in a mixed state. If you want the change anyway, use ⊞ beside the property to gather the pages that answer it, simplify the answers that hold more than words, and try again.
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 catalogs 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 tool 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 tool's actions 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 colors 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 ◑ Color by a property to paint every node by
its value, with a color 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. For a list in a named style, checked by hand, see Reference list under Writing from your sources — it prints only the fields a page actually has.
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.