dig + base64.
Store images in DNS. Base64-encodes an image, chunks it across numbered TXT records, and reconstructs it on the other side with a single command.
An image encoded with name cat under example.com produces records like:
_meta_cat.example.com. IN TXT "chunks=3 filename=cat.webp mimetype=image/webp"
_0._meta_cat.example.com. IN TXT "iVBORw0KGgo..."
_1._meta_cat.example.com. IN TXT "AAAANSUHEU..."
_2._meta_cat.example.com. IN TXT "gAAAABJRU5..."
The _meta_<name> record stores the chunk count, original filename, and MIME type. Each chunk is stored at _<n>._meta_<name>, where n is the zero-indexed sequence number. The decoder reads the meta record first, then fetches chunks 0 through N-1 in order.
bashbase64dig(only needed when decoding from live DNS)
All are standard on macOS and most Linux distributions.
./dig64.sh encode <image_file> <name> <domain> [chunk_size]| Argument | Description |
|---|---|
image_file |
Path to the image file |
name |
Custom name for the TXT records |
domain |
The DNS domain to use |
chunk_size |
Characters per chunk (default: 250) |
./dig64.sh encode cat.webp cat example.comOutputs cat_dns_records.txt containing zone-file formatted TXT records.
Pass the meta record name. The decoder reads chunks, filename, and mimetype from it, fetches the chunks, and writes the file using the original filename.
./dig64.sh decode <record> [--file <zone_file>] [dns_server]| Argument | Description |
|---|---|
record |
The TXT record containing the metadata |
--file |
Read from a local zone file instead of DNS |
dns_server |
Optional DNS server to query |
From live DNS:
./dig64.sh decode _meta_cat.example.com
./dig64.sh decode _meta_cat.example.com 8.8.8.8From a local file (for testing):
./dig64.sh decode _meta_cat.example.com --file cat_dns_records.txt- DNS TXT records have a 255-byte string limit. The default chunk size of 250 stays safely under this.
- A 100KB image produces ~137KB of base64, which is ~548 TXT records.
- Some DNS providers impose limits on the number of records per zone. Check your provider's limits for large images.