Following up on earlier discussion in the features thread and @Eduardo's suggestion to create a dedicated thread.
What is it?
A plugin that provides bidirectional sync between Joplin notes and Google Docs — including images. Edit in Joplin, changes appear in Google Docs. Collaborate in Google Docs, pull changes back to Joplin.
Repository: GitHub - joplin-plugin-google-docs
Why this exists
Teams with technical knowledge scattered in Markdown across dev machines, but company-mandated Google Workspace for official documentation. This bridges that gap — your notes become shareable, collaborative documents without leaving your Joplin workflow.
Current State
This is no longer a proof-of-concept. The plugin has been through a complete migration to the official Joplin plugin template and is distributed as a proper .jpl file (639KB, all dependencies bundled via webpack tree-shaking). The latest progress can be foud in the feat/official-template-migration branch.
What works:
| Feature | Status |
|---|---|
| Export note → Google Doc (with full Markdown formatting) | |
| Import Google Doc → Joplin note | |
| Export entire notebook → Google Drive folder | |
| Push/Pull sync with conflict detection | |
| Image sync (including WebP, AVIF auto-conversion) | |
| Background polling for remote changes | |
| Sync status icons in note list | |
| Setup wizard (OAuth configuration guidance) | |
| Bind/unbind notes to existing Docs |
Markdown conversion: headings, bold/italic, strikethrough, inline code, fenced code blocks (with language detection), links, ordered/unordered lists, blockquotes, horizontal rules, and images.
The image sync story
Getting images to work was... instructive. Google Workspace domain policies can block Drive sharing even when the API reports success. WebP images (common from web clipping) aren't supported by the Docs API. Joplin's plugin sandbox streams behave differently than standard Node.js.
The solution: upload to Google Cloud Storage using direct HTTPS requests (bypassing googleapis stream issues), convert unsupported formats to PNG using Chromium's Canvas API (no external dependencies — Electron gives us browser-native WebP/AVIF decoding for free), and revoke public access immediately after the Docs API fetches the image.
The full debugging journey is documented in the Image Sync Implementation wiki page — might be useful if you're building something similar.
Technical notes
Architecture: Provider-agnostic design. Google Docs is the first backend, but the interfaces support adding other formats (DOCX local export is stubbed).
Sync mechanism: Delta sync via Drive Changes API (only processes changed items), optimistic concurrency using requiredRevisionId checks.
Build: Migrated from custom TypeScript build to official Joplin plugin template. The Webpack Migration wiki documents the complete journey — including the discovery that Joplin's plugin sandbox doesn't extract node_modules from .jpl archives, so static imports with full webpack bundling is the only reliable approach.
Setup
You'll need a Google Cloud project with Docs, Drive, and Storage APIs enabled. The plugin includes a setup wizard that walks through OAuth configuration. The project wiki has 15 pages of documentation covering architecture, implementation details, and troubleshooting.
Scopes required:
drive.file— Only files created by the plugin or explicitly selecteddocuments— Read/write Google Docsdevstorage.full_control— Temporary image upload for embedding (optional, only if you want image sync)
What's next
- Image pull (round-trip images back from Docs to Joplin)
- Tab-based sync (notebook → one Doc, notes → tabs within)
- Submission to the official plugin repository
Caveats
I use this daily with my primary Joplin instance. That said:
- Some edge cases in Markdown conversion may not be perfect
- Conflict resolution is basic (last-writer-wins with dialogs)
- This is developed with AI assistance (Cursor + Claude) — the code has gone through multiple refactoring passes but may still have naming quirks
Feedback, bug reports, and contributions welcome. Particularly interested in edge cases people encounter with Markdown formatting or Workspace configurations.
