Data URI Generator
Turn pasted text into an RFC 2397 data: URI with a chosen media type, charset, and base64 or percent-encoding.
This tool handles input and primary processing in your browser and is designed not to send the input to QuickKit’s server.
Avoid live production secrets; use dummy or masked data where possible. Data handling details
data: URI
How it works
Paste text and choose a media type (default text/plain), an optional charset, and whether to base64-encode or percent-encode the payload. The output follows RFC 2397 (checked 2026-10-12): data:[<mediatype>][;base64],<data>. With the media type left blank, a charset is written as data:;charset=UTF-8,… (the leading semicolon is required).
The payload is always the UTF-8 bytes of the text, so the only accepted charset is UTF-8 (case-insensitive); other labels such as US-ASCII, ISO-8859-1, or Shift_JIS are rejected, even for ASCII-only text, because no transcoding is done. With the charset blank, ASCII-only text is emitted as is, but non-ASCII text is rejected for a blank or text/* media type: a blank type and text/plain default to US-ASCII, and other text types define their own defaults, so the UTF-8 bytes must be labelled. Other media types (for example application/json) get the UTF-8 bytes with no charset asserted.
Unpaired UTF-16 surrogates cannot be encoded and are rejected. A leading U+FEFF is kept as the bytes EF BB BF; many UTF-8 decoders (TextDecoder by default, fetch().text()) read them as a byte order mark and drop that character from the decoded text, although the bytes are unchanged.
Input is capped at 512 KiB of UTF-8. This tool only accepts text — it does not read local files, and it does not guess or assert a media type for you. Very large data: URIs are impractical in real documents; prefer a normal file reference past a few kilobytes.