[BUG] Downloads from an HTML file opened in a conversation: percent-encoded `data:` links fail with an atob InvalidCharacterError; base64 links work

Status Closed — not planned
Maintainer reply None cached
Activity 1 comment · opened Oct 3, 2026 · closed Oct 6, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet.
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code (Claude Desktop 2.19675.0 for macOS, and claude.ai in Chrome, 2026-10-02)

What's Wrong?

I asked Claude in a chat to create an HTML file and deliver it as a file. It appears as a file card in the conversation and opens in the side preview panel (this is not a published Artifact). The file has <a download> links whose href is a data: URI. In both the Claude Desktop app and claude.ai in Chrome:

  • A base64 link (data:application/octet-stream;base64,…) works. The app first shows "Artifacts are created by other users and aren't verified by Anthropic. Only download files you trust." (Cancel / Download file). On Desktop a macOS Save sheet then opens; in Chrome the file goes straight to Downloads. The saved file has the correct bytes (sha256 checked).
  • A percent-encoded link (data:text/plain;charset=utf-8, + encodeURIComponent(text)) saves nothing, and the app shows an error inside the file's frame:

Uncaught Error: Uncaught InvalidCharacterError: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded.

A percent-encoded data: URI is valid, and a normal browser downloads it. The minimal file below has no script at all, so the atob call comes from the app's download handling, which apparently assumes every data: URI is base64. That is an inference: the app's code was not inspected.

What Should Happen?

Percent-encoded (non-base64) data: URIs should download like base64 ones, or the app should say clearly that it can't download them instead of failing silently.

Error Messages/Logs

Uncaught Error: Uncaught InvalidCharacterError: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded.

Steps to Reproduce

  1. Ask Claude in a chat to create t.html containing exactly:

``html
<a download="a.txt" href="data:text/plain;charset=utf-8,hello%20world%0A">text (percent-encoded)</a>
<a download="b.bin" href="data:application/octet-stream;base64,aGVsbG8gd29ybGQK">binary (base64)</a>
``

  1. Open the file from its card in the conversation (it opens in the preview panel).
  2. Click each link.
  3. Observed, on both claude.ai in Chrome and Claude Desktop: the percent-encoded link saves nothing and the atob error appears inside the preview. The base64 link shows the trust dialog, then saves b.bin (12 bytes, correct sha256).

Claude Model

Not model-related.

Is this a regression?

I don't know

Claude Code Version

Claude Desktop 2.19675.0 (5706e5), macOS; claude.ai web (Chrome), same day.

Platform

Anthropic API (Claude subscription)

Operating System

macOS

Terminal/Shell

Other: Claude Desktop app and claude.ai web

Additional Information

  • Minimal file above: n=1 per link per client (Chrome and Desktop), 2026-10-03. First seen the day before with a larger HTML viewer: same result, text link n=1 and binary links n=2 per client.
  • Workaround: use base64 data: URIs for text too (data:text/plain;charset=utf-8;base64,…).

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗