LightCMS vs TinaCMS: Standalone Workspace vs On-Page Editing
Both commit Markdown to Git, but LightCMS is a standalone writing workspace and TinaCMS edits content on the rendered page. Which fits your workflow?
TinaCMS made a compelling argument that most CMS dashboards get one thing backwards: instead of pulling content out of its context to edit it, you should edit it where it lives. Click a paragraph on the rendered page, change it, and commit.
LightCMS makes the opposite bet: long-form writing deserves a dedicated surface, separate from layout, where the document is the only thing on screen.
Both commit clean Markdown to your repository. They disagree about where your hands should be.
Two Philosophies of "Visual"
TinaCMS — contextual editing. You interact with content on the live page. What you edit is what you see rendered, which is the right fit for copy that sits inside a design: headlines, hero text, card titles, metadata next to its visual consequence.
LightCMS — document editing. You interact with the article itself in a focused workspace. There is no layout to distract from structure, and no scrolling past the header image to reach paragraph fourteen.
The distinction maps onto content type:
- Page and landing copy → editing in place is faster and less error-prone.
- Articles, docs, changelogs → a dedicated writing surface is calmer and more productive.
Tina is optimized for the first case; LightCMS for the second.
Comparison
| LightCMS | TinaCMS | |
|---|---|---|
| Editing model | Standalone document workspace | On-page, in-context editing |
| Content store | Your GitHub repository | GitHub (or Git-backed storage) |
| Content schema | Configured in the app; front matter as a form | Schema defined in code with Tina's content SDK |
| Editor | TipTap WYSIWYG — tables, math, code, task lists | Inline rich text tuned for page copy |
| AI copilot | Built in (any OpenAI-compatible endpoint) | Not bundled |
| Voice-to-text | Built in (Whisper) | Not bundled |
| Newsletters | Built in via Newsy — GitHub-backed, no email service | Not bundled |
| Deployment | Self-hosted Node.js service | Local workflow, hosted cloud option, or self-hosted |
| Licensing | Apache 2.0 | Open source core, with hosted services available |
(Verify current licensing and hosted-tier details against each project's docs before committing; both projects evolve quickly.)
Where TinaCMS Wins
- Layout feedback. Editing hero copy inside the hero tells you immediately when a sentence is too long for its box. No dashboard can show that.
- Developer ergonomics for app-like sites. Tina's schema-in-code integrates naturally with component-driven frameworks and type-safe content collections.
- Live preview parity. Because you are editing the rendered output, preview and result are the same thing by definition.
Where LightCMS Wins
- Writing focus. A blank, beautiful page with headings, lists, code, and math — not a page you must scroll to reach your prose inside.
- No schema-in-code step. Adding a field does not require editing a TypeScript config, opening a pull request, and redeploying the site. Writers can manage front matter themselves.
- Distribution. Drafting assistance, transcription, and newsletter dispatch are part of the product, not integrations you assemble.
- Full self-hosting. Run the whole thing on infrastructure you control, with your own model endpoint.
The Schema Question, Specifically
This is the difference teams underestimate:
With a code-defined schema, content structure is a developer concern. That is a feature for engineering teams who want strict typing and review, and a blocker for everyone else: a writer who needs one new field must file a request.
LightCMS treats structure as configuration — front matter fields are managed in the tool. The trade-off is less compile-time type safety; the gain is that metadata evolves at the speed of the editorial calendar.
Choose based on who is allowed to change the content model.
Migration
Both write Markdown with YAML front matter into a repository, so the content itself moves without conversion. What changes is the schema layer: Tina's code configuration gives way to LightCMS's in-app fields, which takes an afternoon at most for a typical blog.
Which Should You Choose?
- Choose TinaCMS if your editing happens against layout (marketing pages, landing copy, component-driven sites) and your team is comfortable defining content structure in code.
- Choose LightCMS if you publish articles, want a real writing environment, and need contributors to work without touching the codebase.
Frequently Asked Questions
Does LightCMS do on-page editing?
No. LightCMS is a dedicated workspace rather than an embedded page editor, so it does not render your live theme while you write.
Is TinaCMS free?
Tina has an open source core with hosted services around it. Check current pricing and licensing for your use case before choosing.
Can both be used on the same repository?
Practically, no — two editing tools would compete over the same files and conventions. Pick one owner for the content workflow.
Which produces cleaner Markdown?
Both produce clean, conventional Markdown and front matter. Editor output is a design choice, not a quality difference.
Do either require a database?
LightCMS does not. Tina's hosted offering stores content in Git-backed storage; self-hosted arrangements vary by configuration.
More comparisons: LightCMS vs Keystatic, LightCMS vs Pages CMS, LightCMS vs Decap CMS.