Check your apple-app-site-association file for iOS Universal Links
Paste your domain and this tool fetches your AASA file the same way iOS does: it checks that the file is reachable over HTTPS without a redirect, served with the correct application/json content type, valid JSON, and contains a non-empty applinks.details array. Free, instant, no signup.
Check your Apple App Site Association configuration
Results will appear here after validation
Enter a domain above to validate your AASA file
Smler hosts and serves your apple-app-site-association and assetlinks.json files for you, kept in sync with your app IDs and certificate fingerprints. One dashboard for Universal Links and App Links across iOS and Android — no manual JSON, no content-type surprises.
Deferred deep linking, short links, and analytics come with the same setup — free up to 25,000 attributed installs a month.
Fetches https://yourdomain.com/.well-known/apple-app-site-association directly and confirms it responds with HTTP 200, exactly the way Apple's crawler does — no redirects, no auth walls.
Confirms the response is served as application/json. Many static hosts default to text/plain for extensionless files, which silently breaks Universal Links even when the JSON is perfect.
Parses the response body and flags syntax errors — trailing commas, comments, or malformed braces are common causes of a silently ignored AASA file.
Checks that the parsed JSON contains a top-level applinks object, the section Apple reads to configure Universal Links.
Verifies applinks.details exists and contains at least one entry — an empty or missing array means no app ID is actually associated with the domain.
You get a plain-language message for the first failing check, so you know exactly what to fix instead of parsing a raw HTTP response yourself.
The Apple App Site Association (AASA) file is a JSON document that establishes a cryptographically verified link between your website and your iOS app. Apple's servers fetch and cache it, then use it to power two features:
webcredentials).Without a correctly hosted AASA file, every link to your site opens in Safari even if the user has your app installed — a common source of lost conversions in app install and re-engagement campaigns.
/.well-known/apple-app-site-association — no .json extension.application/json, not text/plain or text/html.The file either doesn't exist at that path, requires authentication, or the domain returned a non-200 status. Confirm the file is deployed to /.well-known/ at your web root (not inside a subfolder) and that no auth middleware or WAF rule blocks unauthenticated GET requests to it.
Your server or CDN is guessing the MIME type from the (missing) file extension and defaulting to text/plain. Add an explicit content-type rule for the /.well-known/apple-app-site-association route — on Vercel/Next.js this means a custom route handler or header rule; on Nginx/Apache, a type override for that exact path; on S3/CloudFront, set the object's metadata content-type at upload.
Run the raw response through a JSON linter. The usual culprits are a trailing comma after the last array entry, single quotes instead of double quotes, or a stray comment left in from editing.
The file loaded but doesn't have the structure Apple expects. It must contain a top-level applinks object — some older examples online show a flat appID/paths pair from a deprecated schema, which iOS no longer reads.
applinks.details must be a non-empty array, where each entry lists an appID (Team ID + Bundle ID) and the paths it should own. An empty array or a typo'd key name (e.g. detail instead of details) leaves nothing associated.
It is a JSON file hosted on your domain that proves you own both the website and the iOS app, so Apple will let taps on your links open the app directly (Universal Links) instead of Safari.
At https://yourdomain.com/.well-known/apple-app-site-association, served over HTTPS on the apex or subdomain you configured, with no file extension and no redirect in the request chain.
Apple's crawler checks the Content-Type header before parsing the body. If your host serves the file as text/plain or text/html (common on static hosts and some CDNs), iOS treats the association as absent even though the JSON itself is correct.
No. Apple's CDN fetches the file once, does not follow redirects, and does not retry. A 301/302 from HTTP to HTTPS, from apex to www, or from a load balancer health check will cause validation to fail.
applinks configures Universal Links (tapping a web link opens your app). webcredentials is a separate, unrelated section for shared password AutoFill between your site and app. This validator checks the applinks block since that is what powers deep linking.
Yes. Apple enforces a 128 KB limit on the AASA file. If you are associating many app IDs or path patterns, keep the details array trimmed to what you actually route.
Yes. iOS fetches and caches the file when the app is installed or updated. Changes you make after that point will not take effect until the user reinstalls or updates the app, so re-check after any deploy rather than assuming an old install reflects new rules.
This validator confirms the file is reachable and structurally correct, which is necessary but not sufficient. Also verify: the associated-domains entitlement in Xcode matches exactly (applinks:yourdomain.com), the app ID and Team ID in the JSON match your provisioning profile, and the user has not previously tapped "Open in Safari" for that domain (which suppresses the prompt).
No. Validation runs directly from your browser to your domain, requests are not logged or stored, and you do not need an account to use it.
AASA is Apple's format for iOS Universal Links; assetlinks.json is Google's equivalent for Android App Links. The two files live at different well-known paths and use different schemas, so you need both if you support iOS and Android.
Setting up deep linking for both platforms? Check these too: