Overview
Many ABP capabilities produce or consume binary data:| Capability | Binary Output |
|---|---|
export.pdf | PDF document (application/pdf) |
export.image | PNG/JPEG image (image/png, image/jpeg) |
process.image | Processed image data |
generate.qrcode | QR code image |
Why Binary Handling Needs Standardization
Without standardization, each app implements binary handling differently, making agents unable to reliably consume binary responses.Design Decisions
| Decision | Choice | Alternatives Considered | Rationale |
|---|---|---|---|
| Data format | BinaryData wrapper object | Raw bytes, Base64 string only | Wrapper provides metadata (mimeType, size) that agents need for proper handling |
| WebSocket encoding | Base64 in JSON | Binary frames, MessagePack | Base64 is universally supported, JSON-compatible, and simple. ~33% overhead is acceptable for most browser operations. |
| Large file handling | Optional downloadUrl | Chunked transfer, streaming | Simple to implement, works across all transports, avoids memory issues |
| Size threshold | Recommended 10MB | Fixed limit, no limit | Apps know their constraints best; 10MB is a sensible default |
| Streaming | Not in v1.0 | Full streaming support | Adds significant complexity; can be added in future version if needed |
What We Explicitly Chose NOT to Do
- No streaming — Adds complexity, most browser operations produce complete files
- No chunked transfer — Can be added later if large file handling proves insufficient
- No compression requirement — Apps MAY compress, but it’s not mandated
- No binary WebSocket frames in v1 — Base64 is simpler and sufficient for most cases
BinaryData Format
Binary data in ABP responses uses a standard wrapper:Example Response with Binary Data
mimeTypeis REQUIRED — agents need this to handle data correctlyencodingis REQUIRED when content is a string — tells the agent how to decodesizeis RECOMMENDED — helps agents allocate buffers and show progressfilenameis OPTIONAL — provides a sensible default for saving
BinaryDataReference (Large Files)
For files larger than a reasonable threshold (recommended: 10MB), apps SHOULD provide a download URL instead of inline content:Example Large File Response
Agent Handling
Transport-Specific Handling
Each transport has different capabilities for binary data:Puppeteer/Playwright Transport
Puppeteer supports direct binary transfer via structured cloning:postMessage Transport
postMessage supports structured cloning with transferable objects (zero-copy):WebSocket Transport
WebSocket uses Base64 encoding for JSON compatibility:Transport Comparison
| Transport | Binary Format | Zero-Copy | Overhead |
|---|---|---|---|
| Puppeteer | ArrayBuffer | Yes (within page.evaluate) | None |
| postMessage | ArrayBuffer + transfer list | Yes | None |
| WebSocket | Base64 string | No | ~33% size increase |
Binary Input
Some capabilities accept binary input (e.g., image processing):For Puppeteer/postMessage
Agents MAY send ArrayBuffer directly:Capability Schema Conventions
Capabilities that produce binary output SHOULD document this in their schema:Best Practices
For App Developers
- Always include
mimeType— Agents need this to handle the data correctly - Include
sizewhen known — Helps agents allocate buffers and show progress - Use
downloadUrlfor files > 10MB — Avoids memory issues - Set reasonable
expiresAtfor download URLs (1 hour minimum recommended) - For WebSocket, always set
encoding: 'base64'when content is Base64
Example: Size-Based Routing
For Agent/Client Developers
- Check for
downloadUrlfirst — Handle large files appropriately - Verify
sizematches actual content when provided - Use
filenamefor saving if provided, generate sensible default otherwise - Handle both inline content and download URLs transparently