The markup pad: a plain box that marks text in place

Sometimes the job is smaller than an editor

A full rich-text editor brings toolbars, keyboard shortcuts, paste normalisation, undo history and a document model, and all of it can argue with the browser's own typing behaviour. When the task is to read a draft and see what is wrong with it, most of that machinery is weight rather than help.

The pad is deliberately smaller: a plain editable surface, one button that marks the text, one that clears it. There is no formatting to learn, no document to save and no state that survives the tab closing. What it does have is the one thing the task needs — the ability to see flagged terms inside the sentence that contains them.

That reduction matters for a specific kind of reader. Some people are comfortable in a document editor and will use a full one. Others want the equivalent of a text box: type, read, move on. The second group is large and mostly unserved by writing tools, which assume everyone wants an environment.

Marking on demand beats marking on every keystroke

Live marks are useful when you are composing and want immediate feedback on a phrase. They are less useful when you are thinking, because a page that changes colour as you type is a page that keeps interrupting you. The pad marks when you ask it to, and stays still otherwise.

That choice has a practical consequence: the marks always describe the version of the text you asked about. Nothing is half-updated, no mark refers to a word you deleted a second ago, and the count you are looking at is the count for the text on screen.

It also makes comparison possible. Mark the draft, note what you see, edit, mark again. Two readings of the same pad at two moments in time, both accurate, which is more than a live overlay can offer.

Clearing is the other half of the design. One press removes every mark and leaves plain text, so the surface returns to something you can work in without decoration.

What the marks are telling you

The four families are the same ones the editor uses: stock vocabulary, hedges, announcement connectives and absolutes. Read the colour as an instruction rather than an accusation. Turquoise wants a specific, amber wants a decision, purple is usually a deletion and red is a claim that needs a source or a quieter form.

Work the risky end first. A pad pass is short by design, so spend it on the marks that can hurt: the absolute, the guarantee, the emphatic never. Vocabulary edits are pleasant and they can absorb an entire afternoon without improving the argument.

A pad is also a decent place to read someone else's work without being able to change it. Paste, mark, read, clear. Nothing is saved, so the exercise leaves no file behind and no formatting to clean up afterwards.

The one thing to remember before copying out

Marks on this pad are written into the content itself rather than layered over it. That is what makes them editable in place, and it is also the catch: copy the text into a rich-text destination and the mark formatting travels with it.

The fix is one press. Clear removes every mark and gives you plain text, which is what you want in almost every handoff. If you forget, a paste into a client document will arrive with coloured spans, and someone will ask why their paragraph looks like a highlighter test.

Plain-text destinations — a code editor, a terminal, a text file — strip the formatting anyway, so the problem only appears in word processors, email clients and content management systems. Which is, unfortunately, most of the places text actually goes.

Treat the pad as a reading surface and not the file of record. Your document lives in your document. The pad is where you find out what to change in it.

Reading a model's output on the pad

Paste the raw output, not the polished version you have already edited, because the padding is the diagnosis. A generated piece usually arrives with a frame around it: a line that restates the prompt, a closing paragraph that summarises what you just read, a heading that says Introduction. Those survive into publication more often than anybody admits.

Marking stretches that arrive all amber and purple is a fast structural read. Two paragraphs of hedges and announcements at the top means the introduction was scaffolding rather than argument, and the correct edit is usually to delete it and start at the first paragraph that makes a claim.

The pad is particularly good at triage, which is the part of editing people skip. Ninety seconds on the pad answers the question that decides the next two hours: does this need a rewrite or a pass? A draft that lights up in every family needs rewriting; a draft with four scattered marks needs ten minutes.

And because nothing is stored, the pad is the safest surface for text you were not supposed to have. Contract drafts, internal memos, a client's unpublished copy: they can be read and marked without leaving a document behind on a shared machine.

Browser behaviour you should know about

Pasting into a contentEditable surface brings the source formatting with it. That looks fine and it quietly changes what you are marking, because heading styles and bold runs carry weight in how a reader experiences the draft. Use paste as plain text, usually Ctrl or Cmd with Shift and V, and the surface behaves like the text box it is meant to be.

There is no autosave, and that is a design decision rather than an oversight. It is also the thing people forget: the tab is the document, so copy the text before navigating, before switching drafts, and before a browser decides to reclaim memory.

Undo works, but only inside the current session and only within the pad. Restoring a draft you closed by accident is not possible, which is the price of not keeping a copy of what you paste. For a working document, keep the original open elsewhere and use the pad as the reading surface.

On a phone the pad is usable for reading and awkward for writing, because the marks and the cursor compete for the same touch targets. Mark, read, and make the edits in your real document.

Marking, then publishing: a small workflow

The pad is a triage surface. Paste what you have, mark it, decide whether the piece needs a rewrite or a pass, then do the actual editing in the document it belongs to. That sequence takes about three minutes and prevents the most common waste in editorial work, which is polishing a paragraph that should not exist.

It is not the file of record. Nothing is saved, the marks travel with copied formatting, and closing the tab discards everything. All three of those are properties rather than bugs, and together they make it the right surface for reading material that should not be stored anywhere.

Clear before you hand text on. A paragraph pasted out of the pad into a client document arrives with coloured spans and the client, reasonably, asks what happened to their formatting.

• Paste as plain text so the marks describe the words rather than the source styling.
• Mark once for triage, then edit in your real document.
• Press clear before copying anything out of the pad.
• Copy the text before navigating away — there is no restore.

The pad and the console do different work

The pad reads prose and nothing else. It has no opinion on structure, no idea whether the claims are true, and no mechanism for turning what it finds into a report somebody else can act on. Those are the console's jobs, and swapping one for the other leaves a gap.

The sequence that covers both costs about four minutes: console first for the structural and factual findings, pad second for the sentences, document third for the actual edits. Skipping the console means the pad is marking well-formed prose that is about to be rejected for a missing citation anyway.

Where a reviewer is being paid by the hour, that order also happens to be the cheapest version of the review, which is worth mentioning to whoever approves the budget.

What you give up without an editor

A plain pad has no formatting, no comments and no tracked changes, which means the review it supports is a reading rather than a record. For a document that will pass between three people, that is the wrong instrument, and the honest move is to use the pad for the read and the real document for the conversation.

It also has no autosave and no undo history beyond the session, so it suits a draft that arrives finished. Writing a long piece in it is possible and unwise; there is no version to return to when a paragraph goes wrong.

When to use this instead of the highlighter

Use the pad when the draft arrives as plain text, when you want no tool between you and the typing, and when you would rather decide when to look at marks. It is the lightest thing in the toolbox and it is meant to be.

Use the inline highlighter when you are writing and want the feedback continuously, and use the word highlighter when you are judging a finished draft and want density figures rather than marks you can edit around.

Whichever surface you pick, the conclusion is the same: marks change where the fix happens, not whether it happens. A draft that has been through one honest pass reads differently from one that has not, and no tool does the pass for you.