Let's stop pretending a document is paper.

Why we built Docs and why in 2026, the blank A4 page displayed by yesterday word processors is no longer the best paradigm for writing text.

A few numbers to start with. On average, an office worker spends:

• 8 hours a week producing just 5 documents

• 30% of that time on formatting, not writing

• 50% of documents still don't follow the brand guidelines

ℹ️ Source: 2020 B2B Study by the Nielsen Company and Empower GMBH

Include slides and the time spent formatting rises to 5 hours. That's not a rounding error that's most of a working day, every week, spent formatting text instead of writing it.

Document = paper

This doesn't come from nowhere: a normal office in the '90s drowned in paper. Lars Tunbjörk's photo series "Les Bureaux" (1999) captures that period really well.

The word processors we know today were designed around that time. Documents were meant to be printed, so showing an A4 page on screen made sense. So did providing a lot of formatting tools: when you print, you need to check margins, deal with page breaks, and so on.

This is called a skeuomorph.

A skeuomorph is a derivative object that retains ornamental design cues (attributes) from structures that were necessary in the original. Skeuomorphs are typically used to make something new feel familiar and thus easier to understand and use.

ℹ️ From this Wikipedia article (CC BY-SA)

Nowadays, writing text has changed:

• it happens online

• it's collaborative

• sometimes in real time, with 4, 6 or more pairs of hands typing at once

• AI produces some of it, and even intervenes directly in the document

It's time we collectively redefine what a text document is. Regular word processors shouldn't have a monopoly on it. A text document can be as plain as a .md or .txt file: no margins, no ruler, no page count.

The tech community has been relying on these for decades.

With Docs, we built a text editing product that sits between the two, to win everyone over to the idea that many documents don't need complex formatting.

Bringing that change will be transformative for many office workers. Not only will they get back precious hours, it will also redefine how they work together and how they structure knowledge and information.

The excellent "Trapped in Microsoft Office" article from IA.net puts it bluntly:

The office model embedded in Microsoft Office is hierarchical, paper-bound, and authority-driven. It assumes that thinking culminates in a formatted artifact. This model made sense in 1995. It does not make sense in 2026.

Writing is the job, not the interruption

Civil servants and office workers spend their days writing — and not just documents: emails, chat messages, AI prompts.

According to Asana's Anatomy of Work Global Index, employees spend 58% of their time on coordination.

"Work about work" — time spent on work coordination rather than the skilled, strategic jobs they want to do — remains how workers spend the majority — 58% — of their day.

ℹ️ From this NASDAQ press release

Writing documents isn't a minor detail. It's the job. So text editors should help in any way they can. But do they?

Too many buttons, not enough writing

An office worker spends around 23 hours a week in office applications, nearly three full workdays. A significant portion is spent picking fonts, adjusting line spacing, redoing a layout.

These get in the way of writing. Every time you have to make a complex formatting change, you stop writing: hands off the keyboard, grab the mouse, navigate a menu, choose an option.

One document, many names

Collaborating around text files is itself a source of friction. Offline collaboration between different parties quickly becomes time-consuming and error-prone. Who hasn't ended up in an email thread with attachments whose file names betray exactly how many rounds of edits the text has survived, FINAL_REALLY_FINAL_DOCUMENT_V8, or worse?

Indeed, according to the study Bridging the information worker productivity gap: new challenges and opportunities for IT by International Data Corporation (IDC), office employees spend half their time creating and individually managing documents, and the other half on collaborative activities: revisions, approvals, version merging, and signature management. Nearly two-thirds of this collaborative time involves remote stakeholders: colleagues working remotely, other departments, or external partners.

Very often, users find themselves juggling different tools, not always approved by their IT department, to meet sometimes conflicting needs: co-editing and formatting. Reconciliation is often done through copy-paste, sometimes at the expense of confidentiality and with human errors that are inevitable given the number of similar documents being edited.

A slow transition to online

In the 2010s, the private sector moved to online collaborative tools. Government took a decade longer. What finally forced the shift wasn't strategy; it was Covid. Civil servants had to be able to work remotely.

The issue with editing office text files online

These are complex documents. Files in OOXML format (such as .docx, .xlsx, or .pptx) are actually ZIP archives containing a folder and file structure in XML format.

The internal structure looks like this:

- _rels/
- docProps/
  - app.xml      (application metadata)
  - core.xml     (main document metadata)
- word/
  - document.xml (main text content, structured in XML tags)
  - styles.xml   (styles: fonts, colors, margins, etc.)
  - media/       (folder containing images and other media)
  - _rels/document.xml.rels (links to external resources)
- [Content_Types].xml (description of content types in the archive)

The official OOXML documentation spans nearly 7,000 pages, making full implementation extremely difficult for third-party developers.

But those 7,000 pages aren't an accident of history. As Italo Vignoli argues, the specification never described a format designed for interoperability, it described how Microsoft Office already behaved, legacy quirks and undocumented features included. A standard only its author can fully implement is a standard in name only, and every .docx you email to a colleague inherits that asymmetry.

That document, which continues to be regarded as a "seemingly" innocent piece of paper, is in reality no longer a piece of paper — and hasn't been for some time — but an executable file that is interpreted by software, and as such is no longer innocent but, in many cases, the insidious tool of lock-in.

ℹ️ From Italo Vignoli, "How proprietary formats have become Microsoft's main tool for lock-in", The Document Foundation Community Blog, July 2026 (CC BY-SA 3.0)

That makes OOXML poorly suited for online editing. It's packed with thousands of XML tags and hidden remnants from older software, which makes real-time changes slow and clunky in a browser. It wasn't built for the web, so it has no built-in way to handle multiple people editing at once without conflicts, and its structure causes delays when syncing changes online.

What if it could be simpler?

Not all documents require complex formatting.

Your memos, status updates, decision logs and meeting notes probably don't, and there should be a text editor for that. One that anyone can use, whether they're an office worker or a developer. That's what we're building with Docs.

Optimizing time spent on the keyboard

Docs ships with fewer than 10 formatting options, and our goal is to keep it that way.

No font pickers, no line-spacing menus, just:

• bold

• italic

• underline

• strike through

• align

• indent

• text color

• background color

Document structure is built around blocks not formatting. You can choose between paragraphs, quotes, headings, images, equations, diagrams, videos and so on. They all come come preformatted, you can move them around without breaking your layout and best of all: you can create your own!

Docs is packed with useful keyboard shortcuts and is Markdown-compatible so you can stay on your keyboard, writing.

Your document can be as formal as you need it to be (full black and white) or as cheerful (packed with colors and emojis 😉).

One document, one history

Instead of juggling each other's versions over email, with Docs everything sits in one place. Versions are created automatically as you go. Soon you'll be able to visualize who did what and when, thanks to our attribution and rich versioning features.

Built to be used anywhere

Docs is web-native from the ground up, no office format to convert, no syncing between a "file" version and an "online" version. Same experience on desktop, tablet, or phone. Comment on a word, a sentence, a paragraph; check the history to see exactly what changed and why. Real-time collaboration builds trust, because everyone sees who's writing what, live.

Own your archive: import in, export out, always readable

Lock-in isn't only a problem in the moment it's a problem over time. Vignoli's sharpest point is about custody: a public administration that archives its official documents in a format controlled by a private company has effectively placed its institutional memory in that company's keeping. The files open today because the vendor still supports the format. Whether they open in twenty years is a commercial decision, and it isn't yours.

For a ministry, an agency or a city hall, that isn't an IT preference. It's a governance question nobody voted on.

Which means we have to pass the same test. "Trust us, we're open source" would be a poor answer.

The honest answer is that the format isn't ours to control. A Docs document is a Yjs document, and the Yjs binary format has been independently reimplemented in Rust, and from there in Python, Ruby, Swift, C and .NET, by people with no connection to this project. The block types we add sit on top of BlockNote and live in the Docs repository like everything else. There's no undocumented layer, because there is nowhere to put one.

That's the difference that matters. Not our format is open, but several implementations already read it, and we control none of them.

And you don't have to stay to find out. We worked closely with the maintainer of DocSpec to import .docx, and you can export to .odt, .docx, .pdf, .html and .md whenever you like. An editor shouldn't trap you in its own format.

Documents that compound into knowledge

A bigger question sits beneath these everyday frictions: the question of the document itself. An office text document is flat, it's a sequence of pages, designed for print. Knowledge doesn't work that way; it's built through links, cross-references, and hierarchies, closer to synapses than a linear list. That's the shift behind tools like Notion or Obsidian: no longer just storing information, but continuously connecting it.

Docs moves in the same direction with sub-documents: a document can contain others, branch out, and form a living tree instead of a pile of isolated files. That turns a shared document into a living knowledge base instead of a graveyard of "final version" files.

What lies ahead with AI

Andrej Karpathy, recently described a workflow that's become central to how he does research: he feeds an LLM raw source material — articles, papers, repos — and has it incrementally "compile" that material into a wiki of interlinked markdown files. He barely touches the wiki by hand anymore; the model writes it, maintains it, answers questions against it, and files its own outputs back in so the knowledge base keeps compounding. His conclusion:

I think there is room here for an incredible new product instead of a hacky collection of scripts.

ℹ️ Andrej Karpathy, on X

He's right — but look closely at what he actually built. It's personal. One researcher, one Obsidian vault, one model quietly compiling one person's folder of raw material into one person's wiki.

The next frontier isn't personal LLM knowledge bases, Karpathy already solved retrieval and synthesis for an audience of one, it's collaborative ones. And that's a harder problem, because a team generates far more entropy than a single person does.

That's exactly where Docs is headed, and not by accident. Docs already carries the plumbing an individual has to hand-roll with a raw folder and a pile of scripts:

• A tree that's already a wiki. Karpathy compiles a folder of markdown into categorized, cross-linked articles by handing it off to an LLM. Docs' sub-documents are that structure already, except several people build the tree together, live, instead of one person curating a private vault.

• Structured content, not a blob. Docs stores writing as blocks rather than flat, paginated pages, and exports cleanly to markdown, precisely the shape a model wants to ingest, summarize, and re-file.

• Multi-author by default, with attribution intact. Real-time collaboration means Docs already tracks edits and soon will be able to provide the attribution data: who wrote what, and when. The same trust mechanism a shared knowledge base needs the moment a model starts writing into it too: proposed edits, not silent overwrites, whoever or whatever the author is.

Picture Docs a few years out: every document you write feeds a shared base that a model is continuously compiling and re-linking, not a personal wiki you tend alone in Obsidian, but the collective one your whole team is already writing into just by doing its job. Ask three months later "why did we choose X over Y," and instead of fifteen versions of the same document to dig through, you get an answer with the reasoning and the people behind it still attached. A senior hire leaves, and the organization doesn't lose five years of judgment with them, because that judgment was never trapped in one head, or one file, it was already woven into the context everyone shares.

That's the bet: not another AI feature bolted onto a document editor, but a knowledge base built to be collaborative from day one because the tool it grows out of already was.

The document was never the point. Knowledge was.
It's time our tools admitted it.