SOURCE_URL: https://majikah.solutions/products/majik-signature/docs/supported-files-documentation

---
title: "Supported File Formats"
id: "supported-files-documentation"
group: "majik-signature"
type: "products"
version: "0.2.2"
lastUpdated: "2026-04-02T00:00:00.000Z"
difficulty: "Intermediate"
time: "10-15 minutes"
tags: [file-formats, embedding, metadata, pdf, png, wav, mp4, docx, tier-1, tier-2, compatibility, preservation, zip, batch, folder, recursive]
---

# Supported File Formats

> Comprehensive reference for file format support, embedding methods, ZIP and folder handling, and signature preservation across different file types

## Overview
Majik Signature supports signing any file format — from PDFs and images to audio, video, documents, code, archives, executables, and more. This guide explains how signatures are embedded in different file types, how ZIP archives are handled with file-level signing, which formats preserve signatures through standard editing workflows, and how to choose the right format for your use case.

### Any File Format Works

Majik Signature can sign literally any file format — there are no restrictions. Drop in a PDF, PNG, MP4, DOCX, ZIP, EXE, SQLite database, 3D model, font file, or any other binary — it will be signed. The difference is not whether a format can be signed, but how the signature is embedded and whether it survives standard editing operations. This is where the two-tier embedding system comes in. For ZIP archives and folders, a special file-level signing mode automatically extracts and individually signs each contained file.

### ZIP Archives and Folders — File-Level Signing

When you sign a ZIP archive or folder in batch mode, Majik Signature does not sign the container as a single binary. Instead, it extracts the contents, recursively traverses nested folders and nested ZIPs, and signs each individual file with its own embedded hybrid signature. The output is repackaged as a new ZIP that preserves the original directory structure. This approach — called file-level signing — provides significantly stronger security and usability guarantees than container-level signing: each file can be independently extracted and verified without the original ZIP, any individual tampered file is detected even if others are clean, and signatures survive ZIP repackaging because they are embedded in each file's metadata rather than in the container.

> **NOTE:** Why not sign the ZIP container itself? Container-level signing (signing the ZIP binary as a whole) would mean the signature covers the compressed bytes and ZIP metadata — not the original file content. Changing compression settings or file ordering would invalidate the signature without any actual content change. More critically, you could not extract and verify an individual file without the original ZIP. File-level signing solves both problems.

### ZIP and Folder Handling Behavior

| Input Type | Processing | Output | Individual File Verifiable? |
| --- | --- | --- | --- |
| Single file | Direct signing — file signed in place | Single signed file | Yes |
| Multiple files (batch) | Each file signed independently | ZIP of signed files | Yes — each file independently |
| Folder | Recursive traversal — each file signed independently | ZIP preserving directory structure | Yes — each file independently |
| ZIP archive | Extracted, recursive traversal, each file signed individually | New ZIP preserving original structure | Yes — extract any file and verify |
| Nested ZIP inside ZIP | Recursively extracted and processed — inner files signed individually | Repackaged preserving nesting | Yes — at any nesting depth |

*Caption: How Majik Signature processes different container inputs*

### Two-Tier Embedding System

Majik Signature uses a two-tier embedding system to balance broad compatibility with signature durability. Tier 1 (Native Metadata) — for well-known formats with built-in metadata containers (PDF, PNG, JPEG, WAV, MP3, MP4, DOCX, etc.), signatures are embedded directly into the format's native metadata fields. These signatures survive standard open → save round-trips in most tools. Tier 2 (Universal Trailer) — for everything else (RAR, 3D assets, executables, databases, etc.), signatures are appended as a self-describing binary trailer. These signatures do not survive re-encoding or re-muxing but can be cleanly stripped. The tier is chosen automatically based on file format detection — you don't need to configure anything. In batch mode, each file is independently assigned to Tier 1 or Tier 2 based on its own format.

> **NOTE:** File format is auto-detected via magic bytes (the first few bytes of the file) and MIME type sniffing. You don't need to provide hints — Majik Signature figures it out automatically.

### Tier 1 vs. Tier 2 Comparison

| Feature | Tier 1 (Native Metadata) | Tier 2 (Universal Trailer) |
| --- | --- | --- |
| Embedding method | Format's built-in metadata container | Self-describing binary trailer |
| Signature location | Inside the file structure (e.g., PDF /Info dict, PNG iTXt chunk) | Appended at the end of the file |
| Survives re-save? | Yes (most tools) | No (re-encoding strips trailer) |
| Survives re-encoding? | Usually yes (depends on tool) | No |
| File remains valid? | Yes — file opens normally | Yes — trailer is ignored by parsers |
| Detection speed | Fast (metadata scan) | Fast (8-byte magic at EOF) |
| Stripping | Format-specific logic | Universal — remove bytes after magic |
| Use cases | Documents, media, long-term archival | One-time delivery, temporary signing |

*Caption: Key differences between the two embedding tiers*

### Tier 1 Formats — Native Metadata Embedding

Tier 1 formats use each format's built-in metadata container to store the signature. This means the signature is part of the file's official structure and survives most standard editing operations. For example: PDF signatures are stored in the /Info dictionary and XMP metadata stream — visible in File → Properties in most PDF readers. PNG uses iTXt chunks (international text) with the keyword 'majik-signature'. JPEG uses APP15 application markers. WAV uses RIFF LIST INFO chunks. MP3 uses ID3v2 TXXX (user-defined text) frames. MP4/MOV uses a custom 'majk' box inside the moov → udta (user data) container. DOCX/XLSX/PPTX (Office Open XML) store signatures as a ZIP entry named 'majik-signature.json'. HTML/Markdown/source code use comment blocks. Tier 1 signatures are the most durable and are recommended whenever possible.

### Tier 1 Format Support

| Format | Extensions | Handler Name | Metadata Location | Survives Re-save? |
| --- | --- | --- | --- | --- |
| PDF | .pdf | PDF | /Info dict + XMP metadata stream | Yes (most tools) |
| PNG | .png | PNG | iTXt chunk (keyword: 'majik-signature') | Yes |
| JPEG | .jpg, .jpeg | JPEG | APP15 application marker | Yes |
| GIF | .gif | GIF | Application Extension block | Yes |
| WebP | .webp | WebP | EXIF chunk | Yes |
| WAV | .wav | WAV | RIFF LIST INFO chunk | Yes |
| MP3 | .mp3 | MP3 | ID3v2 TXXX frame (description: 'majik-signature') | Yes |
| FLAC | .flac | FLAC | VORBIS_COMMENT metadata block | Yes |
| OGG Vorbis | .ogg | OGG | Vorbis comment header | Yes |
| MP4/M4A/M4V | .mp4, .m4a, .m4v | MP4/MOV | moov → udta → majk box | Yes |
| MOV | .mov | MP4/MOV | moov → udta → majk box | Yes |
| MKV | .mkv | MKV/WebM | Tags segment (Title tag) | Partial (depends on tool) |
| WebM | .webm | MKV/WebM | Tags segment (Title tag) | Partial (depends on tool) |
| DOCX | .docx | Office (DOCX/XLSX/PPTX/ODF) | ZIP entry: majik-signature.json | Yes |
| XLSX | .xlsx | Office (DOCX/XLSX/PPTX/ODF) | ZIP entry: majik-signature.json | Yes |
| PPTX | .pptx | Office (DOCX/XLSX/PPTX/ODF) | ZIP entry: majik-signature.json | Yes |
| ODT/ODS/ODP | .odt, .ods, .odp | Office (DOCX/XLSX/PPTX/ODF) | ZIP entry: majik-signature.json | Yes |
| HTML | .html, .htm | Text/Markup/Source | <!-- majik-signature: ... --> comment block | Yes |
| Markdown | .md | Text/Markup/Source | <!-- majik-signature: ... --> comment block | Yes |
| XML | .xml | Text/Markup/Source | <!-- majik-signature: ... --> comment block | Yes |
| SVG | .svg | Text/Markup/Source | <!-- majik-signature: ... --> comment block | Yes |
| Source code | .js, .ts, .py, .java, etc. | Text/Markup/Source | // majik-signature: ... or /* ... */ comment block | Yes |

*Caption: Formats with native metadata embedding and their handlers*

> **NOTE:** MKV and WebM are listed as Tier 1 but with partial re-save survival. Most tools (VLC, ffmpeg, mkvmerge) preserve the Tags segment, but some transcoders strip it. Test your specific workflow if MKV/WebM signature durability is critical.

### Tier 2 Formats — Universal Trailer Embedding

Tier 2 is the fallback for all formats that don't have a native metadata container Majik Signature knows how to use. The signature is appended as a binary trailer at the end of the file. The trailer structure is: [original file bytes][signature JSON UTF-8][8-byte payload length LE][8-byte magic: MAJIKSIG]. The 8-byte magic at the very end (MAJIKSIG) allows detection and clean stripping without knowing the format. The advantage of Tier 2 is universal compatibility — any file can be signed. The disadvantage is that signatures do not survive re-encoding, re-muxing, or re-compression. If you save a Tier 2 signed file in a different tool or change its encoding, the trailer is stripped. Use Tier 2 for one-time delivery, temporary signing, or when the file will not be edited after signing. Note: plain ZIP archives (used as containers — not as Office Open XML files) are signed at the Tier 2 level when treated as single files; in batch mode they are extracted and each inner file is signed at its own appropriate tier.

### Tier 2 Format Examples

| Category | Extensions | Notes |
| --- | --- | --- |
| Archives (plain ZIP) | .zip | In batch mode, contents are extracted and each file is signed individually at its own tier; as a single file, Tier 2 trailer is used |
| Archives (other) | .rar, .7z, .tar, .gz, .bz2, .xz | Re-compression strips trailer |
| Executables | .exe, .dll, .so, .dylib | Trailer ignored by OS loaders |
| Installers | .msi, .deb, .rpm, .apk | Trailer ignored by package managers |
| Fonts | .ttf, .otf, .woff, .woff2 | Trailer ignored by font renderers |
| 3D Models | .obj, .stl, .fbx, .blend, .gltf, .glb | Trailer ignored by 3D software |
| Databases | .db, .sqlite, .sqlite3 | Trailer ignored by SQLite |
| eBooks | .epub, .mobi | Re-save in e-reader strips trailer |
| Design Files | .psd, .ai, .sketch, .fig, .afdesign | Depends on software |
| CAD | .dwg, .dxf | Trailer ignored by AutoCAD |
| Raw Images | .cr2, .nef, .arw, .dng | Re-export strips trailer |
| Spreadsheets (non-Office) | .numbers, .gnumeric | Re-save strips trailer |
| Audio (exotic) | .aiff, .au, .mid | Re-encode strips trailer |
| Video (exotic) | .avi, .wmv, .flv, .3gp | Re-encode strips trailer |
| Any unknown format | .* | Falls back to Tier 2 |

*Caption: Common file types that use universal trailer embedding*

### Tier 2 Signatures Do Not Survive Re-Encoding

> ⚠️ **WARNING:** If you sign a file using Tier 2 (universal trailer), the signature is only preserved as long as the file bytes are not modified. If you open the file in an editor and save it, re-encode a video, re-compress an archive, or export a 3D model to a different format, the trailer is stripped and the signature is lost. For files that need durable signatures, use Tier 1 formats (PDF, PNG, WAV, MP4, DOCX, etc.).

### How Tier Is Chosen (Automatic)

When you sign a file, Majik Signature automatically detects the format and chooses the appropriate tier. The detection pipeline works as follows: (1) Magic bytes scan — the first 16 bytes of the file are checked against known magic byte patterns (e.g., %PDF for PDF, 89 50 4E 47 for PNG, 52 49 46 46 for WAV). (2) MIME type sniffing — the file extension and MIME type are used as hints. (3) Tier 1 lookup — if the magic bytes or MIME type match a known Tier 1 format, that handler is used. (4) Tier 2 fallback — if no Tier 1 handler matches, the universal trailer method is used. The chosen tier and handler name are displayed in the signature result panel under Embed handler (e.g., 'PDF', 'WAV', 'MP4/MOV', or 'Fallback (Universal Trailer)'). In batch mode, the embed handler is shown per file in the results list.

> **NOTE:** The Embed handler field in the signature result tells you which tier and method were used. If you see 'Fallback (Universal Trailer)', the file was signed with Tier 2 — the signature will not survive re-encoding.

### Signature Stripping (Re-Signing Is Always Safe)

If you sign a file that already has a Majik Signature embedded, the old signature is automatically stripped before the new one is created. This ensures re-signing is always idempotent — you never accumulate multiple signatures. For Tier 1 formats, the existing metadata entry is removed and replaced with the new signature. For Tier 2 formats, the trailer is detected via the MAJIKSIG magic bytes and cleanly removed before appending the new trailer. This stripping logic runs as the first step of the signing pipeline, so the content hash in the new signature always covers the original file bytes before any signature was added. In batch mode, stripping runs per file — each file is independently cleaned before re-signing.

### Files Remain Valid After Signing

Both Tier 1 and Tier 2 embedding methods preserve file validity. A signed PDF is still a valid PDF — it opens normally in any PDF reader. A signed PNG is still a valid PNG — it displays in any image viewer. A signed WAV is still playable in any audio player. A signed MP4 plays in any video player. A signed DOCX opens in Microsoft Word or LibreOffice. The signature is stored in metadata containers or appended as a trailer that parsers ignore — it does not interfere with the file's primary function. The only difference is that the file now has additional metadata or trailing bytes that can be extracted and verified by Majik Signature.

> **NOTE:** Signing a file increases its size by approximately 10 KB due to the signature envelope (Ed25519 64 bytes + ML-DSA-87 4595 bytes + public keys + metadata). This overhead is constant regardless of the original file size — a 1 MB file becomes ~1.01 MB, a 100 MB file becomes ~100.01 MB. In a batch of 100 files, total signature overhead is approximately 1 MB.

### Format Categories

| Category | Tier 1 Formats | Tier 2 Formats | Recommended Tier |
| --- | --- | --- | --- |
| Images | PNG, JPEG, GIF, WebP | BMP, TIFF, ICO, HEIC, PSD, RAW (CR2, NEF, ARW) | Tier 1 (PNG/JPEG) for archival |
| Audio | WAV, MP3, FLAC, OGG | AIFF, AU, MIDI, Opus | Tier 1 (WAV/MP3) for durability |
| Video | MP4, MOV | AVI, WMV, FLV, 3GP | Tier 1 (MP4/MOV) for re-save survival |
| Documents | PDF, DOCX, XLSX, PPTX, ODT, ODS, ODP | Pages, Numbers, Keynote | Tier 1 (PDF/DOCX) strongly recommended |
| Text & Code | HTML, Markdown, XML, SVG, JS, TS, Python, etc. | Plain .txt (no metadata) | Tier 1 (HTML/Markdown) for comments |
| Archives (ZIP) | N/A as container — contents signed individually in batch mode | Tier 2 if signed as a single file | Use batch mode for file-level signing |
| Archives (other) | None | RAR, 7Z, TAR, GZ | Tier 2 only — doesn't survive re-compression |
| Executables | None | EXE, DLL, MSI, DMG, DEB, RPM | Tier 2 only — use for distribution |
| 3D & Design | None | OBJ, STL, FBX, Blender, GLB, GLTF | Tier 2 only — doesn't survive export |
| Fonts | None | TTF, OTF, WOFF, WOFF2 | Tier 2 only |
| Databases | None | SQLite, DB | Tier 2 only |

*Caption: Major file format categories and their support status*

### Choosing the Right Format for Your Use Case

If signature durability matters — the file will be edited, re-saved, or archived long-term — use a Tier 1 format. Convert images to PNG, audio to WAV or MP3, video to MP4, and documents to PDF or DOCX before signing. If you need to sign a collection of files with individual verifiability — use batch mode with drag-and-drop folder or ZIP input. Each file is signed at its own appropriate tier. If the file is for one-time delivery or temporary use — a software installer, a 3D model for a client, or a database snapshot — Tier 2 is fine. The signature will verify as long as the file is not re-encoded. If you're signing source code or markup for version control — use HTML, Markdown, or source code formats (Tier 1) so the signature embeds as a comment block and survives git commits.

### PDF Editing May Strip Signatures in Some Tools

> ⚠️ **WARNING:** While most PDF readers and editors (Adobe Acrobat, Preview, Foxit, etc.) preserve the /Info dictionary and XMP metadata when saving, some PDF manipulation tools (especially command-line utilities like pdftk or qpdf without the --preserve-metadata flag) may strip custom metadata entries. Always test your specific PDF workflow if signature preservation is critical. For maximum durability, avoid editing signed PDFs — or re-sign after editing.

### Signature Durability Reference

| Operation | Tier 1 (Native) | Tier 2 (Trailer) | Notes |
| --- | --- | --- | --- |
| Open and view | ✓ Preserved | ✓ Preserved | Signature is not affected |
| Save without edits | ✓ Preserved | ✓ Preserved | File bytes unchanged |
| Edit and save (same format) | ✓ Usually preserved | ✕ Stripped | Depends on editing tool |
| Export to different format | ✕ Stripped | ✕ Stripped | Format conversion loses metadata |
| Re-encode (video/audio) | ~ Partial | ✕ Stripped | Depends on encoder settings |
| Re-compress (archives) | ✕ Stripped | ✕ Stripped | New archive created |
| Git commit (text/code) | ✓ Preserved | ✕ Stripped | Tier 1 embeds as comments |
| Copy file bytes | ✓ Preserved | ✓ Preserved | File is not modified |
| Email as attachment | ✓ Preserved | ✓ Preserved | File is not modified |
| Repackage in new ZIP (individual files) | ✓ Preserved | ✓ Preserved | The file itself is unchanged — only the container changes |

*Caption: Which operations preserve signatures for each tier*

### Re-Verification After Editing

If you edit a signed file and the signature survives (Tier 1, tool preserves metadata), the verification will still pass — as long as the original content is unchanged. However, if you modify the content (change text in a PDF, crop an image, trim audio), the SHA-256 hash will change and verification will fail with a Content tampered verdict. This is by design — the signature proves the content has not been modified. If you need to edit a signed file, edit it first, then sign the final version. Or, if you must edit after signing, re-sign the file after editing to create a new signature covering the updated content.

> **NOTE:** Re-signing is always safe and idempotent. If you re-sign a file, the old signature is automatically stripped and replaced with a new one. You never accumulate multiple signatures.

### Format Recommendations by Use Case

Long-term archival (10+ years): Use PDF for documents, PNG for images, WAV for audio, MP4 for video. These are Tier 1 formats with strong tool support and signature durability. Software distribution: Use Tier 2 (universal trailer) for executables (.exe, .dmg, .deb, .rpm). The signature verifies before installation, and re-encoding is unlikely. Content provenance (art, music, video): Use Tier 1 native metadata formats (PNG for art, MP3 or WAV for music, MP4 for video). The signature embeds in metadata visible to tools and survives most standard edits. Source code and documentation: Use HTML or Markdown (Tier 1 comment blocks). The signature embeds as a comment and survives git commits, code reviews, and version control. Signing a project folder or release ZIP: Use batch mode — each file is signed individually at its own appropriate tier, and the output ZIP preserves the structure. Any file can be extracted and verified independently. Temporary delivery or one-time use: Any format works — Tier 2 is fine if the file won't be re-encoded.

### Use Case Recommendations

| Use Case | Recommended Formats | Tier | Why |
| --- | --- | --- | --- |
| Long-term document archival | PDF, DOCX | Tier 1 | Survives re-save, widely supported |
| Art and photography provenance | PNG, JPEG | Tier 1 | Metadata survives standard edits |
| Music and audio distribution | MP3, WAV, FLAC | Tier 1 | ID3/RIFF metadata preserved |
| Video distribution | MP4, MOV | Tier 1 | udta box survives most editors |
| Software installers | EXE, DMG, DEB, RPM | Tier 2 | One-time use, trailer ignored by OS |
| Source code version control | HTML, Markdown, JS, TS, Python | Tier 1 | Comment blocks survive git |
| Project folder or release ZIP | Batch mode (folder or ZIP input) | Per-file (Tier 1 or 2) | File-level signing — each file independently verifiable |
| Temporary file delivery | Any format | Tier 1 or 2 | Short-lived, re-encoding unlikely |
| 3D assets for clients | OBJ, STL, GLTF | Tier 2 | One-time delivery, trailer ignored |
| Database snapshots | SQLite, DB | Tier 2 | One-time backup, trailer ignored |

*Caption: Best file formats for different signing scenarios*

### Cross-Platform Compatibility

Majik Signature's embedding methods are designed to be cross-platform compatible. A file signed on Windows can be verified on macOS or Linux, and vice versa. The signature envelope is stored as JSON (UTF-8 text for Tier 1, binary for Tier 2), which is platform-agnostic. However, some platform-specific tools may handle metadata differently. For example, Windows File Explorer may not display custom metadata added to PNGs, but the metadata is still there and verifiable. macOS Preview preserves PDF /Info dict entries, but some Linux PDF tools may strip them. Always test your specific platform and tool combination if cross-platform signature preservation is critical.

> **NOTE:** The Majik Signature web app (signature.majikah.solutions) works identically across all platforms — Windows, macOS, Linux, ChromeOS — because it runs in the browser. The embedding logic is the same regardless of operating system.

### Future Format Support

Majik Signature's format support is actively expanding. Future updates may add Tier 1 native metadata embedding for: AVIF and HEIC (image formats), Opus (audio), AV1/AVIF video, EPUB and MOBI (eBooks), and more executable formats (Mach-O for macOS, ELF for Linux). If you have a specific format you'd like to see added to Tier 1, open an issue on the Majik Signature GitHub repository.