---
title: Slack Renders HTML Attachments Now – What That Changes and What It Doesn't
slug: /blog/slack-renders-html-attachments
publishedAt: "2026-08-18"
updatedAt: "2026-08-18"
priority: P1
keyword: slack render html attachments
secondary_keywords: does slack render html files, view html file in slack, slack html attachment shows as download, share html file in slack, send html file to client from slack
word_count_target: 1600
funnel_stage: Awareness – news-reactive
schema: FAQPage, Article
description: "Since mid-June 2026, Slack has been rolling out inline rendering for attached HTML files: the file displays as a page instead of a download button. That fixes viewing inside the channel. It doesn't give the file a URL, and everything sharing actually means still needs one."
---
# Slack Renders HTML Attachments Now – What That Changes and What It Doesn't
> **TL;DR:** Since mid-June 2026, Slack has been rolling out inline rendering for attached HTML files. Drop a complete `.html` file into a channel and, in workspaces where the rollout has landed, it displays as a page instead of a download button. That fixes viewing. It does not give the file a URL, so the page still can't reach a client outside the workspace, can't be restricted to specific people, can't be updated in place, and disappears into the scroll within days. Those are sharing problems, and they need a published link, not a preview.
---
## 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](https://x.com/trq212/status/2067021344341098670) 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 every workspace. The same file can render as a page in one Slack workspace and show a download button in 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-generated pages in Slack, this is a real improvement. The old behavior – documented in [our rundown of the 7 ways engineers share HTML files](/blog/share-html-file-with-team) – 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 your workspace.** There's no setting to flip; it arrives when it arrives. The same file may already render for a colleague in a different Slack workspace.
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 Claude Code, Codex, and Cursor 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 channel. The page is painted inside each member's Slack client, and that's the entire footprint. No URL is created. Nothing about who can open the page changed – the audience is still exactly the channel membership, decided by whoever manages the channel, not by you.
Sharing is a different problem: giving the page an address, deciding who is allowed to open that address, and having it still work next month. A rendered attachment solves none of it. Concretely, the rendered file still can't:
- **Reach anyone outside your Slack workspace.** A Slack file lives inside Slack. The client, the contractor, the stakeholder without a seat – there is no link you can send them.
- **Go to specific people.** Everyone in the channel sees it, and anyone who joins later can scroll back to it. There's no way to show it to two named reviewers and nobody else.
- **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.
- **Collect review.** Feedback arrives as thread replies about the file, detached from the page itself. Nothing connects "the chart on the right is wrong" to the page, its version, or the agent that will fix it.
- **Be found in a week.** A message is a moment in the scroll. Once it's buried, the page has no address anyone can return to or bookmark.
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 an address with access control and a version history, and a channel provides neither. The render lowers the friction of dropping the file without adding any of what the file actually needed.
## 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](https://app.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](/blog/share-claude-code-artifacts-with-team).
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](/blog/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](/blog/know-if-someone-opened-your-link).
Slack still does what it's good at. The channel gets the conversation and a link it can preview; the page gets an address, an audience you chose, and a place for feedback. Posting a published link is also currently more dependable than attaching the file, since a link works for every recipient while the attachment rendering is still mid-rollout.
## Rendered attachment vs. published link
| | HTML file attached in Slack | Published on display.dev, link posted in Slack |
| ------------------------------------ | ------------------------------------------ | --------------------------------------------------- |
| Displays as a page in the channel | In workspaces where the rollout has landed | Yes – the link opens the page for anyone allowed in |
| Openable outside the Slack workspace | ❌ | ✅ Anyone you've allowed, no Slack seat needed |
| Restrict to specific people | ❌ Channel membership only | ✅ Company SSO, invited emails, private, or public |
| Update without re-sending | ❌ New upload per version | ✅ Same URL, versions stored |
| Comments attached to the page | ❌ Thread replies only | ✅ On the page, per version |
| Findable after a week | ❌ Buried in the scroll | ✅ The URL keeps working |
| Who viewed it | ❌ | ✅ Audit history |
## FAQ
**Does Slack render HTML attachments now?**
In some workspaces, yes. Since mid-June 2026, Slack has been rolling out inline rendering for attached HTML files: a complete `.html` file attached to a message displays as a page in the channel instead of a download button. The rollout is gradual, so the same file can render in one workspace and appear as a download in another.
**Why does my HTML file still show as a download in Slack?**
Either the rollout hasn't reached your workspace yet, or the file isn't being recognized as a complete standalone page. There is no setting that turns rendering on. If a recipient in another workspace reports seeing a download button, that's the rollout, not your file.
**Does HTML code pasted into a Slack message render?**
No. The change applies to file attachments only. Markup pasted into the message body is treated as text, the same as before.
**Is a rendered HTML attachment in Slack private?**
Only as private as the channel. Everyone in the channel can see it, anyone added to the channel later can scroll back to it, and there's no way to limit it to specific people, add an expiry, or share it with one person outside the workspace. It's visible to the room rather than shared with chosen viewers.
**Can someone outside my Slack workspace open an HTML file I posted?**
No. Slack files live inside the workspace, and there's no external link to send. To get the page to a client or contractor, publish the file to a URL with access control and send them the link. On display.dev you can invite their specific email, so the link works for them and nobody else.
**What's the best way to share an agent-generated HTML file from Slack with a client?**
Publish the file rather than attaching it: `dsp publish ./report.html`, or ask your MCP-connected agent to publish it. Set access to the client's invited email, then post the URL in Slack for your own team and send the same URL to the client. They verify their email with a one-time password and see the full interactive page; when the page is revised, the same URL shows the current version.