Oh My PPT: an Electron app that generates HTML slides and converts them back to editable PPTX
Describe what you need — a presentation, lesson, or story — and let the AI build clean, beautiful HTML slides for you. Local-first. Works offline. Works for you.
At a glance
- What is it?
- Oh My PPT is a local-first desktop tool that turns a prompt, a document or an imported PPTX into HTML slides, then exports them as PowerPoint files. The interesting part is the round trip, and the weak part is everything the README leaves unquantified.
- Who is it for?
- Adopt Oh My PPT if you want slide decks you can open in a browser, edit as HTML, and still hand over as PPTX, and if you are willing to configure your own text and image model endpoints, including a local Ollama instance for text. Do not adopt it if you need a signed macOS build, a documented CLI, or a guarantee that a complex imported deck survives the round trip.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is the file format, not the slide design
Most AI slide tools produce a fixed artifact. You get the deck, you like it or you do not, and changing a heading colour means regenerating or editing inside someone else's renderer. The README states the motivation directly: existing tools mostly generate fixed-format files, and adjusting styles or adding animations afterwards is awkward. Oh My PPT takes the opposite position. The generated artifact is HTML, so it opens in a browser, and the styling is something you can change. The audience is people who present regularly (internal reviews, lessons, project pitches, thesis defences) and who already know enough HTML or CSS to want that access. It is not aimed at someone who wants a one-click deck and never wants to see markup. The second audience is people with legacy PPTX files. The README describes importing an existing template or a client file, converting it into pages you can drag, adjust and edit with AI, and extracting the original style for reuse. That is a different job from generation, and it is the part most competing tools do not attempt at all.
How the pipeline actually runs
The flow is linear and the README describes each stage. You start from one of four entry points on the home screen: topic creation, conversational creation, document upload, or template creation. Topic creation takes a subject, a canvas size and a detailed description. Conversational creation runs several turns first to settle the audience, structure and per-page emphasis. Document upload accepts txt, md, csv and docx, and the app extracts a topic, a page count and a description, then keeps referring to the original file during generation. Template creation copies a saved template into a new session and regenerates content into its layout and colour scheme. From there the model plans an outline, a palette and a layout, and emits HTML pages. The canvas is not fixed to 16:9: the README lists widescreen, 4:3, vertical 9:16, vertical 3:4, square 1:1 and Xiaohongshu image formats, and states that generation, preview, editing and export all preserve the real ratio. Page generation is budgeted against the chosen canvas size and a content height estimate, which the README frames as a way to reduce overflow. After generation you can preview, present full screen, or edit. Editing is element-level: drag and resize anything visible, select any element and ask the model to change it, insert images and video, undo and redo, and save version records you can roll back to. Export then runs in two directions: PPTX through a converter the README says is written in-house, and PDF, batch PNG, PNG long image, MP4, or a packaged single-file HTML executable that needs only a browser.
The PPTX converter is the claim that needs your own testing
The README repeats one number in two places: PPTX import and PPTX export each achieve close to 100 percent visual and structural fidelity in ordinary cases. That number is doing a lot of work, and the same paragraphs immediately qualify it. On import, complex shapes, charts, tables, animations, mixed text and extreme layouts are described as still being optimised, with results depending on the original file's PowerPoint features, fonts and asset complexity. On export, text overlap, mixed typesetting, complex charts, tables, shapes and animations are listed as still being optimised. So the honest reading is: simple decks round-trip well, and the hard cases are known to be incomplete. Both the parser and the HTML-to-PPTX generator are described as developed in-house rather than built on an existing conversion library, which explains both the ambition and the long tail of edge cases. If your source material is a clean text-and-image deck, this is probably fine. If it is a consulting template full of grouped shapes, SmartArt and custom animations, treat the fidelity claim as a hypothesis you test on your own file before you rely on it.
Getting it running: download, then configure two separate model slots
Installation is a release download from the GitHub releases page, not a package manager command. The README links the installer and the project ships an Electron desktop app, so the practical setup is: fetch the build for your platform, launch it, and open Settings. Two configuration areas matter and they are independent. The text model handles outlines, page content and conversational edits. The image model handles illustration and backgrounds. The README is explicit that these are two separate configurations, and gives a concrete example: a local Ollama instance can serve text generation, but automatic image placement still needs a separately configured image service. For images, the built-in providers listed are Jimeng 3.0 and 4.0, Agnes AI, Seedream, SiliconFlow, Gemini, and any OpenAI-compatible image endpoint. You can register several and choose per creation or per edit. The README recommends running a real test in Settings before saving: the app generates a test image at the default resolution, and the configuration can only be saved after that test succeeds. That gate is a sensible design choice and worth respecting, because it catches a wrong key or an unreachable endpoint at setup time rather than halfway through a deck. Fonts are configured the same way: 14 bundled Google fonts including Chinese faces, plus upload of local .woff2 files with a custom name and category, and title and body fonts can be set separately or left to the model.
Where it stops being the right tool
The macOS signing situation is the first hard limit. The README devotes a section to the unsigned application problem, including the macOS damaged dialog, which means the build is not notarised and users hit Gatekeeper friction on first launch. If your organisation blocks unsigned binaries, this is a blocker before any feature discussion. The second limit is the image pipeline. Automatic illustration during creation adds generation time, the README says so plainly, and it requires a verified image provider. With text on Ollama and no image service configured, you get text-only decks and must generate visuals manually from the edit panel. The third limit is the absence of any documented command-line interface or headless mode. Everything described is desktop UI: home screen entries, a settings panel, an editor canvas, a presentation mode. If you wanted to generate decks from a build script or a CI job, nothing in the supplied material supports that. The fourth is the model dependency itself. The README notes that image prompts and necessary page semantics are sent to whichever image provider you select, so the local-first claim covers storage and session data, not the inference calls. Your prompts leave the machine unless you are running a local image model, and the listed providers are hosted services.
Compared with Marp, which solves an overlapping problem differently
Marp is the closest well-known tool in spirit: it turns Markdown into HTML slides and can export to PDF and PPTX. The difference in approach is where the authoring happens. Marp is text-first and deterministic. You write Markdown with directives, run a command, and get the same output every time; the styling comes from CSS themes you control, and nothing is generated by a model. Oh My PPT is model-first. You describe intent, the model produces the outline and the HTML, and you steer the result through conversation and direct manipulation. That makes Oh My PPT better when you do not yet know what the deck should say, and worse when you do. A Marp deck is diffable, reviewable in a pull request, and reproducible on a build server. An Oh My PPT deck is a session with version history, edited in a GUI. The other difference is the PPTX direction. Marp converts its own Markdown to PPTX; Oh My PPT also imports existing PPTX files into an editable state, which Marp does not attempt. If your workflow already lives in a repository, Marp fits it. If your workflow starts from a client's PowerPoint template, Oh My PPT is addressing a problem Marp ignores.
Licence, maintenance and what upgrades cost you
The project is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes; it also includes a patent grant. That is a permissive arrangement, and it is a real difference from tools that gate export behind a subscription. It does not, however, cover the AI providers you connect: their terms, content policies and per-image costs are separate agreements, and the README points at exactly that. On maintenance, the release cadence is visible in the supplied data: v2.5.0 on 2026-09-04, v2.5.1 on 2026-09-05, v2.5.2 on 2026-09-09, with the last push to main on 2026-09-05. Three releases in six days suggests active iteration, and it also suggests you should expect to re-download builds rather than sit on one version. Sessions, source documents, assets and generated images are stored locally, and the README describes exporting a session so another machine can import it and continue editing, which is the migration path when you change computers. There is no stated long-term support policy, no versioned data migration notes, and no backup guidance beyond that export. If you build a library of decks on this, the session export is the thing to keep, and the format of those session files is the thing to watch across major versions.
Editorial conclusion
Adopt Oh My PPT if you want slide decks you can open in a browser, edit as HTML, and still hand over as PPTX, and if you are willing to configure your own text and image model endpoints, including a local Ollama instance for text. Do not adopt it if you need a signed macOS build, a documented CLI, or a guarantee that a complex imported deck survives the round trip. Before committing, verify three things yourself: run the image model test in Settings, import one of your own worst-case PPTX files and inspect the result page by page, and export that same deck back to PPTX to see what the converter does with your tables, charts and animations.
Community notes