Quarto Pub vs RPubs vs Posit Connect vs GitHub Pages: where to publish a Quarto or R Markdown report

The render finished. The report looks right in your browser: the tabsets switch, the figures are sharp, the code is folded away. Now it has to reach a client, a co-author or your advisor, and you go looking for the publish button.

quarto publish offers you a handful of destinations, and RStudio has its own Publish button. Almost every one of them is built to put the report on the open web. That's what you want for a blog post or a teaching notebook. It's not what you want for a client's numbers or a chapter nobody has signed off yet.

Is the report meant to be public, or for specific people?

This one question removes half the options.

The one-click destinations are designed for publishing. Quarto's own documentation is explicit about its free service: "all documents and sites published to Quarto Pub are publicly visible." That isn't a flaw. Quarto Pub exists so that a talk, a tutorial or a paper's companion site can be read and cited by anyone.

A report for one client, a thesis chapter going to a committee, an analysis with a partner's data in it: those are deliveries, not publications. They need to open for the people you send them to and stay out of search, and that's a different kind of tool.

What are the ways to publish a Quarto or R Markdown report?

There are six common routes, and each one is designed for a different job:

If you're weighing a password on GitHub Pages or Netlify, which free plans let you password-protect a page goes host by host.

The details that change (visibility, size limits, passwords) are in this second table, dated and taken only from each vendor's own pages:

Checked on each vendor's own documentation on 1 October 2026. "Not stated" means we couldn't find it on their pages, not that they don't offer it. Vendors change their limits without telling us, so check their site for what's current. Our own row comes from our plan limits. RPubs' own homepage says it retires in June 2027 and that existing documents stay accessible through 31 December 2031, with Connect Cloud as Posit's recommended home for new publishing.

Why does my report lose its styling when I send the HTML?

Because by default the report isn't one file.

We rendered a plain Quarto HTML report on 30 September 2026 with the default settings. Quarto wrote report.html and, next to it, a report_files/ folder holding the stylesheets, the JavaScript and a web font the page loads. Send report.html on its own and the reader's browser looks for that folder, doesn't find it, and shows the report without its theme. Anything that depends on those scripts, such as tabsets and code folding, stops working too.

There are two fixes, and both work.

Put everything in one file. Add this to the document's YAML header:

format:
  html:
    embed-resources: true

Quarto then inlines the styles, scripts and images into the HTML itself. Our test report came out as a single file of about 1.2 MB, which is small enough to email or upload anywhere. Reports with heavy interactive widgets grow fast, because each widget's JavaScript library gets inlined too. Check the file size before you pick where it goes.

Or zip the folder. Put report.html and report_files/ into one ZIP and upload that. The folder structure survives, so the relative paths still resolve. On miinideck the HTML file at the top of the ZIP becomes the page, and every file type in our test render's folder (CSS, JavaScript, fonts) is one we serve. The best free way to host a ZIP bundle covers the ways a zipped site can still break.

R Markdown has the same choice under a different name: the self_contained option of html_document. The rmarkdown documentation lists it as on by default (self_contained = TRUE), so a knitted report is normally one file already; the same page notes that MathJax, if you use it, still loads from the web. We tested the Quarto side only. We haven't rendered an R Markdown report for this page, so open your own output folder and check what's actually there before you send it.

Which one should I use?

The short version:

• It should be public and citable, like a talk, a tutorial or a paper's companion. Quarto Pub, or Posit Connect Cloud's free plan, which is public too.
• It lives in a repository and should be versioned with the code, like a book or a project site. GitHub Pages or Netlify through quarto publish.
• It needs to run code when someone opens it, like a Shiny app or a dashboard that queries a database. That needs a server. See the next section.
• It's a finished report for a client, a co-author or a committee. Render one self-contained file (or zip the folder) and send it through a private link.

For the wider question of which channel suits a report going to one named client, sharing an HTML report with a client compares email, drives and links side by side.

What won't any of them fix?

A few things belong to the report, not to where you put it.

Server-side code needs a server. A Shiny app, a parameterised report that re-runs on demand, or anything that queries a database when it opens can't be carried by a static file, on any of the routes above. Shiny apps go on a service built for them, such as shinyapps.io or Posit Connect. What a file host carries is the pre-rendered slice, where the computation already ran.

Anything fetched when the page opens isn't in your file. A map widget loads its tiles from a tile server each time someone opens the report. Whether they load depends on that server and its rules, not on your render. We haven't tested map tiles on our own viewer, so if your report has a map, open the link in a private window before you send it.

What's rendered is readable. Hiding code with echo: false hides the code. The data behind an interactive chart is still inside the HTML, and anyone can view the page source. If a widget was built from row-level data you shouldn't hand over, aggregate before you render.

When a private link is the right shape

That's the job miinideck is built around: a finished report, going to specific people, where you want to keep hold of the link.

Compared with the routes above, what it changes is who controls the link after you send it. The address can't be guessed and stays out of search, so the report reaches the people you send it to and anyone they forward it to, and you can add a password when that isn't enough. With an account you can re-render and replace the file at the same link, so version two doesn't need a second email. Turn on Review and anyone holding the link can pin comments to a specific plot or table without making an account. The reader needs a browser and nothing else: no R, no account, no download.

The upload itself, and what you can do without an account, are on host a Quarto report as a private link; the file-size limit on each plan is on the pricing page. A report can also stand in for a slide deck. If you're presenting research findings, user research findings as a private HTML report walks through why that format holds up.

---

And if you're still deciding where your file should live at all, where to put a file online maps every option by what you're holding.