LocalStudio: a browser-only slide editor that keeps AI edits as layers

The problem LocalStudio picks: sync as the failure point

The README states the motivation directly: iCloud sync issues can lose or corrupt entire presentations, and translating a deck by hand is slow. LocalStudio answers both by treating the deck as a layered document stored on your disk instead of a remote workspace that owns the file. Import a .pptx and it becomes an editable project. Ask for slides or images and the result arrives as text, image and shape layers rather than a flattened bitmap, so you can keep editing. Translate selected text, the current page, or the whole deck in place. The audience is narrower than "everyone who makes slides": it is people who already run Chrome, are willing to enable experimental browser AI, and would rather own a folder of project JSON and assets than trust a sync client. If your workflow depends on real-time collaboration between several editors, this is not the tool, because the README describes a local-first surface and does not document multi-user co-editing.

How the pieces fit: workspaces, layers and browser AI

The repository is an npm workspaces monorepo with apps/* and packages/*, and the root package.json lists four buildable workspaces: @localstudio/landing, @localstudio/editor, @localstudio/joystick and @localstudio/docs. The editor is the studio itself; the joystick workspace is the companion PWA used for presenter remote control, which the README says runs over peer-to-peer browser connections. Typechecking extends further, covering @localstudio/analytics-config, @localstudio/app-routes, @localstudio/brand and @localstudio/presenter-remote as well. That split tells you where the boundaries are: shared UI and routing live in packages, the four apps are separate deployables.

The AI layer is not a server. It is Chrome's built-in APIs plus Transformers.js. The repository topics name chrome-prompt-api, chrome-translate-api, chrome-language-detection-api, chrome-built-in-ai, speech-to-text and transformers-js. So prompt-to-slide, prompt-to-image, translation and live transcription all execute in the browser, and WebGPU model caches are listed among the requirements. The data flow is therefore: layers in memory, assets written to a local folder you choose, optional mirroring to an S3-compatible endpoint for public sharing. There is no product backend to operate, which also means there is no server-side fallback when a browser API is missing.

Installing LocalStudio and running the editor locally

The README points to the hosted docs at localstudio.dev/docs for usage walkthroughs, and the root package.json defines the scripts. Node 26 is the version shown in the README badges, so match it before installing. From a clone of the repository, install dependencies at the root and start the development script:

npm install
npm run dev

The dev script is node scripts/dev.mjs, and it is the single entry point for local development. If you only want the editor workspace rather than everything, the root scripts also expose per-app commands such as npm run build:editor, which maps to the @localstudio/editor workspace. Expect the first AI action to be slow: the README lists WebGPU model caches among the requirements, meaning model weights are fetched and cached by the browser on first use.

For the S3-compatible path, the repository ships a docker-compose.minio.yml at the top level. MinIO is the self-hosted example the README names, and it says the same project mirror shape fits AWS S3, Cloudflare R2 or any compatible endpoint. What gets mirrored is specific: project JSON, assets, version history, config, public share payloads and mirrored fonts. Local fonts are mirrored too, so a shared deck keeps its typography on the viewer's side.

Where LocalStudio breaks: Chrome-only APIs and no server fallback

The most consequential constraint is the browser. The README describes the project as Chrome-first and lists browser APIs, WebGPU model caches and local storage expectations under Requirements. Translation depends on the Chrome Translate API with language detection, prompt generation depends on the Chrome Prompt API, and live transcription depends on the native Speech-to-Text API. If you are on Firefox or Safari, or on a Chrome build where these are not exposed, those features are simply unavailable, and because there is no backend there is nothing to fall back to. This is a deliberate trade: the same absence of a server is what keeps the deck local.

A second gap is documentation depth. The README is strong on outcomes and demos and thin on operational detail. It does not document rollback for a bad translation pass, it does not describe conflict handling if two people point at the same local project folder, and no releases were retrieved, so there is no changelog to read for upgrade behaviour. The public view includes what the README calls a small RAG app for audience questions, but the retrieval scope and limits are not spelled out there. Treat those as things to inspect in the code and docs before you depend on them.

LocalStudio compared with a cloud deck editor

A cloud presentation tool such as Canva or Google Slides keeps the authoritative document on its servers, resolves edits through its own sync layer, and gives you export formats as the way out. LocalStudio inverts that: the authoritative copy is a local project folder holding project JSON, assets, cache and version snapshots, and publishing is the optional step. The practical difference shows up when something goes wrong. In the cloud model a sync bug is a data-loss event you cannot inspect. In the local model you can open the folder, read the JSON, and copy it elsewhere. The cost is that you give up real-time co-editing and the guarantee that any browser works. It also means backup is your job: the README describes local project history and version snapshots, but it does not describe an automatic off-machine backup. If you want a hosted editor with no setup, LocalStudio is the wrong pick. If you want an editable deck you can inspect with a file manager and translate without uploading, the trade is worth understanding.

Licence, maintenance and what an upgrade costs

The project is MIT licensed, which permits commercial and private use and modification provided the copyright notice and permission notice are retained. That is the standard permissive position; the LICENSE file at the repository root is the binding text and nothing here substitutes for reading it. The repository is not archived, and the last push was on 2026-09-13, days before this writing, so the codebase is moving. There were no retrieved releases, which matters for upgrades: with no tagged versions and no changelog, you are tracking main, and a pull can change workspace scripts, browser API assumptions or the project file shape. The root version field reads 0.1.0, consistent with pre-1.0 software where the project file format is not yet a stability promise. Budget for reading diffs on the packages you depend on, and keep a copy of any project folder you care about in the format your current checkout writes.

Presenter mode, transcripts and the public audience view

The presenter path is the part that differs most from a plain slide editor. Presenter mode adds speaker notes, slide controls, fullscreen playback and PWA remote control, with the joystick workspace acting as the remote over peer-to-peer browser connections. While presenting, the speaker can record their voice and use the native Speech-to-Text API to transcribe the talk; the README says the live transcript opens in a separate window so the session is easier to follow and more accessible. That transcript is then reusable. Public deck viewers can read it alongside speaker notes, and the public view includes podcast-style playback so each slide can be replayed with its matching recorded narration. For a conference talk or a recorded lecture this is a genuinely different shape from exporting a PDF. The caveat is that the transcript quality is the browser's speech recognition, not a paid transcription service, and the README does not state which languages or accents are covered.

Editorial conclusion

LocalStudio fits people who already work in Chrome, want an editable layered deck rather than a locked export, and are comfortable running a Node 26 monorepo with npm workspaces. Skip it if your team is on Safari or Firefox, if you need collaborative multi-user editing, or if you cannot install a browser that exposes the Prompt API and Speech-to-Text API. Before committing, verify three things on your own machine: that chrome://flags exposes the AI APIs your build expects, that npm run dev starts the editor workspace without errors, and that saving a project to a local folder produces the JSON and asset files you would need to restore it.

Frequently asked questions

Official sources

1. ErickWendel/localstudio on GitHub
2. Issues
3. License: MIT
4. Project website
5. README