Why does SharePoint download my .html file instead of showing it?

Because custom script is disabled by default. Microsoft turns off custom scripting (the NoScript setting) on modern SharePoint sites and OneDrive, which means `.html` files in a document library are served as downloads rather than rendered as pages. It is a tenant-level security posture, not a per-file setting you can toggle.

Should I enable custom script to make it render?

Almost certainly not. Enabling custom scripting on a site lets any uploaded file run script in your tenant's origin, with access to the signed-in user's SharePoint session — which is exactly the risk the default protects against. Most security teams will not approve it, and the ones that do usually regret the blast radius. Publishing the report to an isolated sandbox elsewhere gets you the rendered page without that trade.

Does OneDrive render HTML?

No. OneDrive's preview handles Office documents, PDFs, images and video. An `.html` file gets a generic preview and a download button, and the mobile app has no HTML renderer at all.

What about opening it in the SharePoint mobile app?

It offers to download or to open in another app. On iOS there is often no app that will render it properly, which is the case that usually ends the conversation and sends people looking for a link.

How do I share an HTML report with people inside my company?

Publish it to a URL with per-report access. Comma renders the report faithfully in a sandboxed iframe and lets you restrict the link to your team or to everyone signed in at your domain, so an internal report does not need to be public to be readable.

SharePoint and OneDrive won't open your HTML file

You put the report in a document library, sent the link, and your colleague got a download prompt. Or a preview pane that shows the file name and nothing else.

It isn't a permission you forgot to grant.

What's blocking it

Modern SharePoint sites and OneDrive ship with custom script disabled — the setting usually referred to as NoScript. With it off, an .html file in a document library is served as a file to download, not as a page to visit. Microsoft made this the default deliberately, and applies it to newly created sites on an ongoing basis.

The reason is worth understanding, because it also explains why the obvious fix is a bad one. A rendered HTML file in a SharePoint library runs in your tenant's origin, with the signed-in user's session attached. Anything in that file can read what that user can read. That is a very large amount of trust to extend to a coverage report someone generated on a laptop.

So: yes, a tenant admin can enable custom scripting on a site collection and the file will render. And no, you almost certainly should not ask them to, for a report.

The other half of the problem

Even with rendering enabled, most tools that produce "an HTML report" produce a folder — index.html plus a sibling directory of CSS, JavaScript and JSON. Playwright, Allure, nbconvert, genhtml, Sphinx and Storybook all do. Upload the single file and every reference in it resolves to nothing. See why the report lost its CSS.

The fix: publish it somewhere isolated

Drag the file — or the whole output folder, or a zip — into Comma:

index.html becomes the report body.
Sibling assets upload with it, and relative src/href references are rewritten to the uploaded copies.
Scripts run inside a sandboxed iframe (allow-scripts, no allow-same-origin). The report gets to be interactive; it does not get access to anyone's session, cookies or storage. That is the containment boundary SharePoint's NoScript default is trying to preserve, applied per-report instead of per-tenant. See the security model.

Keeping it internal

Access is set per report: private to you, your team, anyone signed in at your domain, or anyone with the link — with view, comment or edit rights for link holders. Domain-gated is usually the right setting for the report that would otherwise have lived in a document library. Full model in sharing & access control.

From a pipeline, if it regenerates

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html report.html '{html: $html}')"

One saved report id, a revision per run, one permanent URL — including from Azure DevOps, which is likely where the pipeline already lives. See Azure DevOps HTML reports and API tokens.

Then: comment instead of forwarding

Once it has an address, review happens on the report. Select the figure, leave a thread, and it stays anchored there across revisions — instead of a fork of the file per reviewer and a chain of replies in Outlook. See commenting on HTML, and share an HTML report in Teams for the unfurled-link version.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total.
Scripts run, sandboxed — no same-origin access to your session.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish your HTML report →