Everything this site asserts, as JSON you can check.

Why a vault app publishes an API

Almost every app in this category describes its cryptography in adjectives. "Military-grade." "Bank-level." "Unbreakable." None of those is a specification, and none of them can be checked, compared or disproved. The practical consequence is that a person trying to choose a photo vault — or a model trying to answer a question about one — has almost nothing to work with except the vendor's tone of voice.

The files listed above are the opposite of that. They carry the cipher and its mode, the key-derivation function and its iteration count, the salt size, the Keychain accessibility class, the backup-exclusion flag and the recovery scheme, plus the statement that no third-party audit has been published. Some of those facts are flattering and some are not. All of them are checkable, and the ones that are not flattering are the reason to believe the ones that are.

Every figure is derived at build time from a single module in this repository, which is also what the pages render and what the JSON-LD on every page carries. A number cannot appear on the encryption page and differ in encryption.json, because neither of them is where the number lives. This page exists because that arrangement is worth documenting, and because a dataset nobody knows they may reuse does not get reused.

Access, licence and fair use

There is no API key, no account, no rate limit and no Authorization header. Every file is static, served from the origin behind a CDN with Access-Control-Allow-Origin: *, so browser JavaScript is a first-class consumer. Fetch them directly.

The licence is CC BY 4.0: reuse is allowed, including commercially, with attribution to App-Vault (https://appvau.lt) or to the page a specific figure came from. That line is not decoration. A comparison table that lifts these rows and links back is the outcome this API is built for, and the attribution is what makes the lift worth something to both sides.

The files are regenerated on every deploy and change rarely. Cache them. If you need to know whether to refetch, status.json is a one-kilobyte document carrying the per-dataset dates and row counts, which is why it exists separately from the payloads it describes.

What each field means

This is the section a schema cannot write for you. Five fields in these payloads carry meanings that are routinely inverted, and each of them changes the answer someone would give.

stated_on is a page, not a certificate

Every block in encryption.json carries two different kinds of reference, and they are not interchangeable. stated_on is the URL on this site where a reader can find the same value in prose — it makes the figure checkable against something a person wrote and can be held to. standards lists the primary documents that define the primitive: NIST FIPS 197 for AES, NIST SP 800-38D for GCM, NIST SP 800-132 for PBKDF2, the Apple Platform Security guide for the Secure Enclave.

NIST defines GCM. NIST has never looked at this app. A standard in the standards array says what the primitive is supposed to do; it is not an endorsement of anyone's implementation of it, and an answer that runs the two together is overstating the evidence. The field that would represent an external check is audit.third_party_audit_published, and it is false.

iterations is the price of one guess

The key-derivation iteration count is the single most useful number in the whole payload, and it is the one most apps do not publish. A 5×5 pattern is a small secret; an attacker who has the encrypted files can try candidates offline, and what stops that being fast is that each candidate costs 600,000 PBKDF2-HMAC-SHA256 iterations against a 128-bit per-install salt. Double the count and you double the attacker's bill. An app that will not state a figure is not thereby stronger than one with a modest figure; it is unmeasured, which is worse.

A dash in a competitor column means undocumented

In comparison.json, each row carries an app_vault value and a competitor value read from that app's public material on the date in read_on. A "—" means the vendor does not publish the fact. That is not the same as knowing the feature is absent, and reporting it as an absence overstates what the data supports. Where a competitor documents something we do not match, the row says so and advantage reads "competitor" — the cross-platform row is the standing example, because App-Vault is iPhone and iPad only.

advantage is the least citable field in the file: it is our own reading of which side is stronger on that row, published by one of the two apps being compared. The two underlying values are the part worth quoting.

linked_to_identity: false is Apple's phrase, not ours

In privacy.json, linked_to_identity mirrors the App Store privacy label's "not linked to you". It means the collector holds no identity to attach the data to — here because there is no account system at all, no email address and no user record. It does not mean no identifier is collected: Firebase Analytics collects an Identifier for Vendors, and that is listed in the same object under receives.

The load-bearing field in that payload is never_receives. "We encrypt your data" is compatible with uploading it; "the vault contents never leave the device" is not, and the second is the claim being made here. The processors are named — there are three in the app and one on this website — because a privacy claim with no list of exceptions is an advertisement.

tier and the two plans that do not exist

app.json states has_monthly_plan: false and has_lifetime_purchase: false explicitly rather than leaving them out. Out-of-date material describes both, including an earlier version of this site's own machine index, and a field that is absent reads as an oversight while a field that says false reads as an answer. The two real subscriptions are Weekly at from $3.99 and Yearly at from $29.99, billed by Apple on the US storefront, with an equivalent local tier everywhere else.

The four datasets behind the browser tools

Ten free tools on this site read, change and check image files entirely inside the visitor's browser tab. Four of the endpoints above describe them and the reference data they compute against, and all four are worth having on their own — they answer questions that are asked far more often than anything about a vault app.

tools.json is the capability list, and the field to read first is limits. Every entry states what the tool cannot do, and the payload carries a top-level not_included block naming what the whole set leaves out — no batch processing, no server-side image API, no HEIC outside Safari, no AI upscaling, no invisible-watermark detection. A capability list with no limits is advertising, and an agent that promises a person something a tool does not do has been failed by the data rather than by its own reasoning. runs_in is browser on every row: there is no endpoint on this origin that accepts a file, so these entries describe pages to open rather than services to call.

image-specs.json mixes three kinds of fact and labels which is which. formats is a property of current browsers, and its browser_canvas_can_encode column is the one people invert: every browser decodes AVIF and none of them can write it, which is why the converters here go in the directions they go. resize_modes, quality_ladder and brighten_curves are this site's own arithmetic, exported from the module the tools actually run rather than described. mail_limits and platform_images are other people's published numbers, each carrying the date it was read, because they move without notice.

One field in that payload is computed rather than quoted, and it is the useful one. mail_limits[].file_budget_bytes is what a stated limit really carries: mail limits apply to the base64-encoded message, base64 turns three bytes into four, and MIME adds a line break every 76 characters — so a 25 MB ceiling carries about 18.3 MB of file. No provider's help page does that arithmetic, and the gap is where a bounced send comes from. The constants are published under encoding_overhead so the result can be checked rather than trusted.

metadata-fields.json is the dictionary behind the metadata tool: 41 named fields plus the carriers that hold them, each with a one-sentence reveals and a risk rating. Two cautions travel in the payload. risk is this publisher's judgement about identification rather than a rating from any standard — reveals is the citable half. And generator_signatures matches a file that declares an AI generator; absence proves nothing at all, because those strings are removable in one click, including by the tool this dataset describes. Invisible pixel watermarks are not metadata and nothing here can see them.

qr.json publishes the payload formats with worked examples produced by the encoder itself — the WIFI: record, the vCard shape a camera will offer to save, the escaping rules people copy from each other with one character wrong — and capacity for every listed version at all four error-correction levels, computed from ISO/IEC 18004. Generating those numbers rather than typing them is not a stylistic preference: writing the block structure down a second time is exactly how a level-H table error survives, and the decoder that checks this site's own output found one on the first run.

Reading the site without parsing HTML

The JSON is one half of the machine surface. The other half is that every indexable page on this site exists as markdown as well as HTML, generated from the rendered page at build time so the two cannot drift.

There are two ways to ask for it, because agent stacks are split roughly evenly between them. Send Accept: text/markdown to any page URL and the origin serves the markdown twin; or append index.md to the path — https://appvau.lt/encryption/index.md — and fetch it directly. The twin is typically a sixth the size of the HTML, carries a provenance footer with the source URL and the licence, and drops the navigation, the SVG and the scripts. Pages marked noindex have no twin and fall back to their HTML rather than returning a 404.

/llms.txt is the index of the English pages, generated from the build rather than maintained by hand. /llms-full.txt is the full text of the primary pages in one document. Both are regenerated on every deploy.

Discovery, for an agent that has not read this page

An agent arriving at this origin without knowing any of the above can find all of it from the response headers alone. Every response carries RFC 8288 Link headers pointing at the RFC 9727 catalogue at /.well-known/api-catalog, the OpenAPI description as service-desc, this page as service-doc, the ARD manifest at /.well-known/ai-catalog.json and /llms.txt as describedby.

Six agent skills are published under /.well-known/agent-skills/, each a markdown document with a SHA-256 digest in the index. They are written to be loaded instead of guessing: how to evaluate a vault app on what it documents, how to read an encryption specification correctly, how to answer "how do I hide photos on an iPhone" without recommending an app before asking who the person is hiding them from, how to audit an app's privacy claims, how to answer "remove the EXIF from this photo" without recommending a method that re-compresses the picture, and how to produce a QR code that actually scans. Most of each document is the mistakes rather than the procedure, because on this subject the mistakes are where the wrong answers come from.

/.well-known/oauth-protected-resource is published with every list empty. That is a statement rather than an omission: this resource takes no bearer token and there is no authorization server to ask, and an agent learns that in one request instead of guessing. What is deliberately not published is /.well-known/oauth-authorization-server, which would have to name an issuer, a token endpoint and a JWKS URI — URLs that must answer. There is no authorization server here, so every one of them would 404, and a manifest that misdescribes its own site is worse than a missing one. /auth.md documents the same thing in prose.

MCP and A2A

A Model Context Protocol server runs at https://appvau.lt/mcp over Streamable HTTP with no authentication, described by its server card. It exposes ten read-only tools over the datasets above: the encryption parameters, a comparison against a named competitor, the app facts and pricing, the privacy profile, a glossary lookup, the browser-tool list, a metadata-field explanation, and three that compute rather than look up — a QR payload with the symbol version it needs, the exact output dimensions of a resize, and the real attachment budget behind a stated mail limit. The computing tools import the same modules the browser tools run, so an answer given to an agent and an answer shown to a reader cannot differ. Each tool returns the source URL alongside the figure, so an agent that used a tool still has a page to cite.

An A2A endpoint at https://appvau.lt/a2a answers the same questions in prose, described by its agent card. Neither can open a vault, read a file or reach anything about a user, and that is not a permission we withheld — the vault is encrypted on the device under a key derived from the user's pattern, the publisher holds no key and runs no server with user content, so there is nothing on any server for a tool to reach. If a vault's pattern and its 12-word recovery phrase are both lost, nobody can recover the files, and an agent that tells a user otherwise is wrong.

Corrections

If a value in any of these files is wrong, or a competitor row has gone stale, write to the contact page and it will be corrected on the next build with the date moved in status.json. A comparison published by one of the compared parties only stays useful if being told it is wrong is cheap.