Dillinger is a free, MIT-licensed, cloud-native Markdown editor built on Next.js and the Monaco Editor, intended for developers, bloggers and writers who want focused writing in the browser with the option to sync finished documents to cloud storage they already use.

What it is

Dillinger is an open-source web application written in TypeScript and licensed under MIT. Its stack is Next.js 14 for the framework, Monaco Editor for editing, Tailwind CSS for styling, Zustand for state, and Lucide for icons, with a Node.js 18+ runtime and support for npm, yarn, pnpm or bun as the package manager. The project has 8,286 stars, 1,156 forks and 157 open issues on GitHub, with the most recent push dated 21 June 2026, and a hosted instance at dillinger.io. Its repository holds 294 unit and integration tests written in Vitest plus 39 end-to-end tests in Playwright, reported at 98 percent code coverage.

The problem it addresses is stated directly in the README: most Markdown editors are bloated, offline-only, or short on serious developer ergonomics. Dillinger answers each of those complaints in turn. It embeds the Monaco Editor, the core of VS Code, instead of a stripped-down textarea; it renders a preview in real time with scroll sync; and it connects through OAuth to GitHub, Google Drive, Dropbox, OneDrive and Bitbucket so documents can stay in storage the user already owns rather than a proprietary silo. Within the JavaScript and Node.js ecosystem, it replaces the familiar combination of a general-purpose text editor and a separate preview tool, as well as the class of standalone desktop Markdown editors that hold files only on one machine.

Key capabilities

• Editing runs on the Monaco Editor, described in the README as the VS Code core, with Markdown syntax highlighting and image paste support.
• A real-time preview with scroll sync provides an instant feedback loop as text is typed.
• Zen Mode, bound to Cmd/Ctrl + Shift + Z, gives a fullscreen, distraction-free writing surface.
• Files can be dragged and dropped in .md, .txt and .markdown formats, with auto-save handled through local persistence.
• Documents export to Markdown, HTML and PDF.
• Cloud integrations cover GitHub, Google Drive, Dropbox, OneDrive and Bitbucket, each configured through OAuth with callbacks such as /api/github/callback and /api/google-drive/callback.
• The application layer is Next.js 14 with Tailwind CSS for styling, Zustand for state and Lucide for icons.

Who uses it and how

• Developers who want VS Code-style editing in a browser tab and keep work on GitHub or Bitbucket can register an OAuth application and edit against those repositories directly.
• Writers and bloggers can work in Zen Mode and export to PDF or HTML without leaving the editor.
• Teams self-hosting the project deploy with npm run build and npm start, then update every OAuth callback to https://yourdomain.com/api/{provider}/callback for their own domain.
• Organisations standardised on a particular provider can register scoped credentials, such as an Azure App Registration with Files.ReadWrite and User.Read for OneDrive, or a Dropbox scoped app with files.metadata.read and files.content.write.
• Individuals who do not want to run any infrastructure can use the hosted instance at dillinger.io instead of deploying the code themselves.

Getting started

Install and run locally with npm install followed by npm run dev, which serves the editor at http://localhost:3000 on Node.js 18 or later; production deployments use npm run build and npm start, with a .env.local file supplying the client ID, client secret and redirect URI for each cloud provider.

How it compares

This registry entry names no comparable tools, so Dillinger stands alone in it. The nearest reference points in the facts are the broad categories the README argues against, namely Markdown editors that are bloated, offline-only, or weak on developer ergonomics, and the Monaco Editor it borrows from VS Code.

When to use it — and when not to

A self-hoster must register and maintain OAuth applications for each cloud provider they enable, including redirect URIs that change with the deployment domain; no database, SMTP service or object store is mentioned in the README, so the operational surface appears to be the Node.js application plus whatever credentials the chosen providers require. The documented deployment path is limited to the npm scripts, with no Docker image or compose file provided. It is a poor fit for anyone who needs a server-side document store or multi-user collaboration, since the README describes none, and the 157 open issues suggest a project with a substantial backlog.

npm install
npm run dev

.env.local

# Google Drive
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
GOOGLE_REDIRECT_URI=http://localhost:3000/api/google-drive/callback

# OneDrive
ONEDRIVE_CLIENT_ID=
ONEDRIVE_CLIENT_SECRET=
ONEDRIVE_REDIRECT_URI=http://localhost:3000/api/onedrive/callback

# Bitbucket
BITBUCKET_CLIENT_ID=
BITBUCKET_CLIENT_SECRET=
BITBUCKET_REDIRECT_URI=http://localhost:3000/api/bitbucket/callback

# GitHub
GITHUB_CLIENT_ID=
GITHUB_CLIENT_SECRET=
GITHUB_REDIRECT_URI=http://localhost:3000/api/github/callback

# Dropbox
DROPBOX_CLIENT_ID=
DROPBOX_CLIENT_SECRET=
DROPBOX_REDIRECT_URI=http://localhost:3000/api/dropbox/callback

/api/google-drive/callback

/api/github/callback

https://yourdomain.com/api/{provider}/callback

npm run build
npm start

npm run dev              # Start dev server
npm run build            # Production build
npm start                # Start production server
npm run lint             # ESLint
npm run test             # Unit + E2E tests
npm run test:unit        # Vitest unit/integration tests
npm run test:watch       # Vitest watch mode
npm run test:e2e         # Playwright E2E tests
npm run test:e2e:headed  # E2E in visible browser
npm run verify           # Lint + typecheck + all tests

npm run test:unit                # Run all unit tests
npx vitest run --coverage        # With coverage report
npm run test:e2e:headed          # E2E in visible browser