How to Host Reveal.js Slides

Zip your built Reveal.js folder, drop it, and you get a URL you can paste into a calendar invite. That is the whole job. Here is what you get:

• A client-facing link in seconds, not a GitHub Pages project or a laptop running npm start.
• Revisions on one URL. Fix a chart, upload again, the same link shows the new build.
• Present without screen-sharing your laptop. Open presenter mode on Friday from the same link.

Reveal.js is a solid way to write slides as HTML. Sharing them is the part people improvise: you push a build folder to Pages, or you zip the project and hope the recipient knows which file to open. None of those is how to share an HTML presentation as a client-facing URL.

Whether you are a developer presenting research or a marketer whose engineer handed you a Reveal folder, the outcome is the same. Recipients open a browser. They do not clone a repo, run Node, or guess which file is the deck.

What you actually need to upload

Reveal.js projects contain more than slides. For hosting, send a built, self-contained folder:

• Your entry HTML at the root (or inside one top-level folder, which is unwrapped for you).
• The CSS, themes, fonts, and images that the deck references with relative paths.
• The bundled scripts your deck needs to run.

Do not upload the entire git repo with dependencies. You will hit the 10 MB free upload cap and ship junk. A zip of the export you would have dropped on any static host is the right artifact.

Host vs GitHub Pages vs npm start

Approach	Good for	Pain
Local Reveal server	Authoring	Recipients cannot open your localhost
GitHub Pages / Netlify	Recurring, versioned sites	Setup, repos, “which URL is prod?”
Presentation host	Talks, client sends, live present	Upload finished builds; 10 MB on the free plan

Use Pages when the deck is documentation you deploy on every merge. Use a host when the job is “send this by Thursday and present it on Friday.”

Prezzly accepts the zip, keeps your revisions, and serves the deck so slide navigation and presenter control work in the browser. If you are generating a new deck from scratch, following Prezzly’s suggested slide structure gives the cleanest result; most existing Reveal markup still runs as-is.

Which Reveal features keep working

Most decks just work: your layout, styling, transitions, and the scripts that drive your slides. A few things to check before you rely on them:

• Anything that depends on the browser remembering state between visits (some speaker-note plugins do this) may not carry over. Use Prezzly’s own speaker notes instead. See speaker notes for HTML presentations.
• Very wide or very tall custom themes may letterback against a standard 16:9 frame.

The rule of thumb: open the hosted link once and click through before the talk. If something looks off, it is almost always a missing asset in the zip, not the deck itself.

Publishing from Cursor

If the Reveal project already lives in a repo you edit with an agent, skip the upload screen entirely. Connect via Model Context Protocol (MCP) and let the agent publish the built files for you. MCP for presentations covers the setup.

Ask the agent to publish the build output, not the source tree, and tell it you want a presentation. Next time you change a slide, ask it to update the same deck so the link stays the same. This is the fastest loop for a living talk: you keep editing Reveal in your repo, and each rebuild is one prompt away from being live for your audience, with no upload screen in between.

Presenting a hosted Reveal deck

You do not have to screen-share your laptop running Reveal’s presenter window. Open presenter mode on the host, send viewers the link, and optionally go live so they follow your slide. That is the same flow as present without screen sharing.

Reveal’s own speaker-view popup is a separate thing. Prezzly shows you per-slide notes on your screen while the audience sees only the deck. You can keep either mental model, but the audience should be on the hosted link, not on a tiled share of your IDE.

Revisions, assets, and the 10 MB ceiling

You will fix a typo after the dry run. Rebuild locally, upload again to the same deck. Viewers with the current link see the new files. Restore an earlier version if the “fix” was worse. The free plan keeps the last 10 versions, so do not treat the host as infinite git history.

If a theme looks unstyled on the hosted URL, you usually left a CSS or assets folder out of the archive. If the zip is over 10 MB, you are usually shipping recordings, dependencies, or uncompressed images. Compress images, drop plugins you are not using, and zip only the folder you would have deployed to a static host. For a talk you give once, a thin build beats keeping a whole Pages project alive.

Frequently Asked Questions (FAQ)

Can I host a Reveal.js deck without GitHub?

Yes. Zip the built folder and upload it. You get a view URL. No repository required.

Will my Reveal plugins keep working?

Most do. Anything that relies on the browser remembering state between visits may not. Open the hosted link and test before the talk.

Do viewers need to know it is Reveal.js?

No. They open a link. They should not install Reveal or Node.

Can I keep using Reveal’s markdown slides?

Yes, if your build step already turned that markdown into the HTML files you upload. The host serves your built files.

Is there a Reveal-specific importer?

No. Reveal is HTML. Treat it like any other self-contained deck.

---

Have a built Reveal folder ready? Host your Reveal.js deck with a drag-and-drop and send the view link instead of a repo URL.