Slack Renders HTML Attachments Now – What That Changes and What It Doesn't

Slack's inline HTML preview removes the download step, but a file attachment still lacks named-viewer access, version history, and page-level review.

What changed

In mid-June 2026, people started noticing that Slack renders attached HTML files inline, as a page in the channel, instead of showing a download button or the raw markup. A widely shared X thread surfaced the change, and the reaction was mostly relief: the file people attached was always meant to be looked at, not downloaded and opened in TextEdit.

The change is narrow, and two details matter:

• It's a gradual rollout. As of mid-July it still hadn't reached everyone. The same file can render as a page for one Slack customer and show a download button for another, so you can't yet count on any given recipient seeing the rendered version.
• It applies to attachments, not messages. A standalone .html file attached to a message renders. HTML code pasted into the message body still displays as text.

For anyone who shares agent-produced pages in Slack, this is a real improvement. The old behavior – documented in our rundown of the 7 ways engineers share HTML files – was a paperclip icon, a download, and a recipient staring at raw markup. Now, at least some of the time, the channel sees the actual page.

Why your HTML file still shows as a download or as code

If you attach an HTML file and don't get a rendered page, one of three things is happening:

1. The rollout hasn't reached you. There's no setting to flip; it arrives when it arrives. The same file may already render for a colleague using a different Slack account.
2. You pasted the code instead of attaching the file. Markup inside a message body is treated as text. Only a file attachment gets the rendering path.
3. The file doesn't read as a complete page. The rendering applies to standalone HTML documents. A fragment, or a page that depends on files sitting next to it, won't display the way it does in your browser. Self-contained files – inline CSS and JavaScript, no external references – are the reliable case, which is conveniently what Cursor, Codex, and Claude Code produce by default.

Viewing and sharing are different problems

It's worth being precise about what inline rendering does, because it makes an attached file look finished in a way that hides what's still missing.

Rendering answers "what does this page look like" for the people already in the conversation. The page is painted inside each member's Slack client. Slack also gives the file a permalink, and paid plans can create an external link when Slack's sharing settings allow it. The preview changes how the attachment displays; it does not add named-viewer access, version history, or review tied to each revision.

Slack's own file-sharing guide documents searchable files, internal links, and external links on paid plans. Those links distribute the uploaded file. They do not turn it into a page whose audience, current version, and review history you manage independently from Slack. Concretely, the rendered file still can't:

• Grant access to named outside reviewers. An internal link follows Slack membership. An external link broadens access to the file, but it does not invite two specific email addresses and reject everyone else.
• Separate the page audience from the conversation. Inside Slack, access follows the channel, direct message, Slack Connect conversation, or sharing policy where the file was shared.
• Be updated. When the page changes, you upload a second file. Now the channel holds v1 and v2 as separate attachments, and nothing marks which one is current.
• Keep review tied to a version of the page. Slack supports file comments and thread replies, but that conversation is not attached to a versioned page the agent can update.

None of this is a criticism of the feature. A preview inside the channel is genuinely useful. The trouble starts when the preview is treated as distribution.

Why this matters now: agents write HTML

The reason a rendering tweak drew a long thread is that HTML files stopped being a niche thing to share. Cursor, Codex, and Claude Code all produce self-contained HTML as a default output format – reports, dashboards, architecture diagrams, working prototypes. An agent finishes the page, and the fastest way to show a colleague is to drop the file in a channel. Rendering makes that path feel complete.

But agent output is usually the material with the most demanding audience. It's the analysis meant for one client, the prototype meant for two reviewers, the report that will go through three revisions before it's right. That work needs named-viewer access, one URL for the current version, and review connected to the page. The render lowers the friction of dropping the file without adding those controls.

Publish the file, then post the link

The move that works is to give the file a URL first and let Slack carry the link instead of the file.

Publishing the page to display.dev takes one step from wherever the file was made:

• From a terminal: dsp publish ./report.html returns a URL in about 15 seconds.
• From an agent: with the display.dev MCP connector, ask your agent to publish and it returns the URL in the conversation. Setup is covered in the Claude Code guide.

The URL is where the sharing problems get solved, because access is a property of the page rather than of a channel:

• You choose who can open it: everyone at your company, specific invited people, only you, or public. Colleagues sign in with the Google or Microsoft account they already use; an invited outside reviewer verifies their email with a one-time password. Nobody needs a Slack seat or a new account. The access model is described in what is gated publishing.
• Updates land at the same URL. When the agent publishes v2, the link everyone has now shows v2, and the earlier versions stay stored behind it.
• Review stays attached. Comments live on the page, tied to the version they were made on, instead of scattering through a thread.
• It stays findable. The Slack message can scroll away; the URL keeps working, and you can see who opened it.

Slack still does what it's good at. The channel gets the conversation and a link it can preview; the page gets an audience you chose, one URL for the current version, and a place for feedback. Posting a published link is also currently more dependable than attaching the file, since a link works for every allowed viewer while the attachment rendering is still mid-rollout.

Rendered attachment vs. published link