FDD is to PDF what Git is to a printed code-review. It’s alive, it’s versionable, and it’s secure.
OpenFDD aims to replace "visual-first" static documents (like PDFs) with "data-first" interactive containers that are human-readable, machine-verifiable, and self-persistent.
FDD files treat the browser as an OS, allowing for a zero-infrastructure application experience where the file is the state.
- Verified Origin: Support for layered digital signatures (JSON Web Signatures) lock down the read-only integrity block, meaning tampering is immediately detected natively.
- AI-Native: Contains a dedicated
ld+jsonblock for zero-OCR machine parsing. Don't give AI a hallucination-prone PDF, give it cryptographically verified JSON-LD. - No-JS Security: Rendering exclusively relies on Declarative HTML and CSS-only logic to prevent malware/smuggling. The container explicitly forbids script execution.
- Local Persistence: Embraces the File System Access API for secure, local-first write-back. It enables the "1-file CRM" model where the file seamlessly saves to your disk.
- Universal Viewing: Paired with a browser extension (or eventual native browser support) that treats
.fddas a High-Trust Data Container and maps proper File Handlers.
/spec: The FDD Standard Definition./docs: Extensive guides on authoring No-JS.fddUI layouts and integrations./lib/node-fdd: Server-side Node library for batch generation and cryptographic signing of FDD files./lib/fdd-js: Browser-side logic-less parsing, data binding, and Local State file handling./extension: The Chrome extension establishing the.fddMIME type routing and Security Shield./examples: Prototypes demonstrating dynamic bank statements, 1-file CRMs, and more./site: Project landing page.
FDD adoption solves both infrastructure and data consumption bottlenecks. We believe in:
- Open Source & License-Free: An open specification without licensing or proprietary constraints drastically reduces the capital required to generate and maintain documentation.
- Zero-Translation Efficiency: Reduced processing cost per document generation because there is far less translation necessary from input data to the output file structure.
- Pristine Data Access: Removes the requirement of LLMs, OCR, and brittle XML parsing to access data (which often yields imperfect results). Get the pristine raw data payload effortlessly without translation errors or a complicated setup.
- Interact Your Way: FDD separates presentation from true data. View it with the built-in UI, load it into an office suite, use it for data modeling, query it directly in your coding IDE, or feed it to an AI Agent—the choice is yours.
- Decentralized APIs: Removes the massive root infrastructure cost of building API endpoints for institutions. Instead of building webhooks to support parallel and downstream industries (e.g. the mortgage industry needing bank statements, or colleges needing school records), institutions can simply issue a secure, verifiable
.fddfile to the user.
The OpenFDD ecosystem provides a full suite of JavaScript libraries to securely compose, sign, view, verify, and interact with FDD files.
Before issuing documents, generate your institutional Ed25519 keypair and host your public identity:
npm install -g @coreyburns/node-fdd
# Generate your Ed25519 keypair
fdd-identity keygen ./keys
# Generate a W3C DID Document for hosting at https://yourdomain.com/.well-known/did.json
fdd-identity did ./keys/public.pem yourdomain.com# Combines packing + cryptographic signing with your issuer DID
fdd-sign pack template.html data.json ./keys/private.pem did:web:yourdomain.com output.fddOr use the programmatic API:
import { generateIdentity, createDidDocument } from '@coreyburns/node-fdd/identity';
import { signFdd, parse, verify } from '@coreyburns/node-fdd';
const identity = generateIdentity();
const didDoc = createDidDocument(identity.publicKeyBase64, 'bank.com');
// Host didDoc at https://bank.com/.well-known/did.json
// Issue a document
const fddString = signFdd(data, htmlTemplate, identity.privateKeyPem, 'did:web:bank.com');
// Consume on a recipient server
const { valid, issuer } = await verify(fddString); // resolves did:web, checks Ed25519
const { vc, mutable } = parse(fddString); // extracts data, no OCR neededRender .fdd containers in your web platform. The library now automatically resolves the issuer's did:web identity and displays a cryptographic trust badge:
<!-- Pinned to v1.2.0 — includes did:web verification & trust badge -->
<script src="https://cdn.jsdelivr.net/gh/Spuds0588/open-fdd@v1.2.0/lib/fdd-js/src/fdd.js"></script>For end-users opening .fdd files from disk. Acts as a Security Shield: sandboxes rendering, enables direct file-system saves, and strips malicious embedding vectors.
The success of OpenFDD relies entirely on community pushback against static PDFs. The best advocacy strategy is loudly sharing and writing about the project publicly! Help spread the word!
Share the Standard on Social Media:
Action Items for Devs and Advocates:
- Write & Record: Create YouTube dev-logs, HackerNews posts, and Medium blogs leveraging your sphere of influence to evangelize why data-first local documents resolve massive privacy/architecture bugs.
- Pressure Vendors: Publicly ask Browsers (Google/Apple), SaaS providers (Hubspot/Workday), and App Developers to explicitly add native support for exporting mapping capabilities using the
.fddopen-standard. - Pitch it to your PM: If your app exports user dashboards as 'PDF Printouts', propose securely exporting an
.fdd"mini-app" instead. - Build Integrations: Build robust parsing libraries in Rust, Python, or Go for the
fdd-datalayer! - Star the Repo: Help signal to the W3C and major browser vendors that developers desperately want explicitly trusted High-Trust File Sandbox permissions natively!
Join us in creating the future of standard file formatting.