Smler
← Back to Tools

AASA Validator

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.

Validate AASA File

Check your Apple App Site Association configuration

Note: You must keep your file in /.well-known/apple-app-site-association path

Validation Results

Results will appear here after validation

Enter a domain above to validate your AASA file

Skip Hand-Rolling AASA and Assetlinks Files

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.

Ship Deep Links Without the Config Drift

Deferred deep linking, short links, and analytics come with the same setup — free up to 25,000 attributed installs a month.

Get Started Free
Set up Universal Links in minutes
No credit card required

What This Validator Checks

1. File Availability

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.

2. Content-Type Header

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.

3. Valid JSON Syntax

Parses the response body and flags syntax errors — trailing commas, comments, or malformed braces are common causes of a silently ignored AASA file.

4. applinks Key Present

Checks that the parsed JSON contains a top-level applinks object, the section Apple reads to configure Universal Links.

5. Non-Empty details Array

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.

Pass / Fail Result

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.

What Is an AASA File?

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:

  • Universal Links: tapping a link to your domain opens your app directly instead of Safari, if the app is installed.
  • Shared Web Credentials: AutoFill can share saved passwords between your site and app (configured separately under 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.

Where the AASA File Must Live

  1. 1
    Exact path: /.well-known/apple-app-site-association — no .json extension.
  2. 2
    HTTPS only: Apple will not fetch the file over plain HTTP.
  3. 3
    No redirects: the request must resolve directly — HTTP→HTTPS or apex→www redirects both break it.
  4. 4
    Correct content type: served as application/json, not text/plain or text/html.
  5. 5
    Under 128 KB: Apple rejects larger files outright.

Common AASA Errors and How to Fix Them

“AASA file not found or not accessible”

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.

“Incorrect content type”

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.

“File is not valid JSON”

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.

“Missing 'applinks' key in JSON”

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.

“Missing or empty 'details' array in applinks”

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.

Frequently Asked Questions

What is an apple-app-site-association (AASA) file?

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.

Where exactly does the AASA file need to live?

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.

Why does content-type matter if the JSON is valid?

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.

Can the AASA file be served through a redirect?

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.

What is the difference between "applinks" and "webcredentials"?

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.

Is there a file size limit?

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.

Does iOS cache the AASA file?

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.

My AASA file is valid here but Universal Links still open Safari. Why?

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).

Does this tool store the URLs I check?

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.

How is this different from validating assetlinks.json?

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.

How do I check my AASA file?

Enter your domain as a full URL, for example https://yourdomain.com, in the box at the top of this page and click Validate. The validator requests /.well-known/apple-app-site-association from that domain and lists five checks, each marked Pass or Fail, under a Validation Successful or Validation Failed headline. Fix the first failing check, deploy the change, and run it again.

What does Apple require of an AASA file?

Apple's documentation asks for a file named apple-app-site-association, with no extension, in the /.well-known/ directory of your fully qualified domain. It must be hosted over HTTPS with a valid certificate and with no redirects. For Universal Links, the JSON needs an applinks object whose details array lists your app IDs and the URL components each app handles. This validator checks the file's availability, content type, JSON syntax and applinks structure.

Related Tools

Setting up deep linking for both platforms? Check these too:

Android Assets ValidatorLink Preview TesterAll Tools

What the AASA validator checks

The validator requests https://yourdomain.com/.well-known/apple-app-site-association from your browser and runs five checks on the response. They appear under Validation Details in this order, each marked Pass or Fail.

  1. 1
    File Availability: the request comes back with a success status. A fail means the file is missing, blocked or erroring at that address, and the headline shows the HTTP status the validator received.
  2. 2
    Content Type: the Content-Type header contains application/json. A fail means your server labels the file as something else; the row shows the value it sent.
  3. 3
    Valid JSON Format: the response body parses as JSON. A fail means a syntax error, or that there was no file to parse.
  4. 4
    Applinks Configuration: the JSON has a top-level applinks key. A fail means the file carries no Universal Links configuration.
  5. 5
    Details Array: applinks.details is an array with at least one entry. A fail means no app is associated with the domain.

The result is Validation Successful only when all five pass. The validator is not tied to Smler: enter any domain and it requests that domain's AASA file, whichever provider hosts it. It reads the structure of the file only, so it does not confirm that the app IDs or paths inside match your app.

Reading the AASA file validator's results

A run ends in one of three states. There is no warning state.

Validation Successful

All five checks passed and the message reads “AASA file is valid and properly configured”. The file is reachable and well formed; next, test on a real device with our guide on how to test deep links on iOS.

Validation Failed

At least one check failed. The headline names the first failing check, and each row shows its own Pass or Fail. One failure can cause later ones (a missing file cannot be valid JSON), so fix from the top down:

  • File Availability: publish the file in /.well-known/ at the domain root, with no login or firewall rule in front of it.
  • Content Type: set the response header for that path to application/json.
  • Valid JSON Format: run the file through a JSON parser and fix what it rejects.
  • Applinks Configuration: add the top-level applinks object.
  • Details Array: add at least one entry to applinks.details.

Failed to validate AASA file

“Failed to validate AASA file. Please check the URL and try again.” means the request never completed, so no checks ran. Check the domain for typos and that it serves HTTPS with a valid certificate. A server that refuses your browser's cross-origin request gives the same message; if so, open the file's address in a new tab to read the raw response.

If every check passes and links still open in Safari, the cause is outside the file: see the deep link troubleshooting guide.

The apple-app-site-association file: where it lives and what it contains

Apple looks for the file at one address on each domain you associate with your app: https://yourdomain.com/.well-known/apple-app-site-association. The file name has no extension. Apple's documentation requires it to be hosted over HTTPS with a valid certificate and with no redirects.

For iOS Universal Links, the part that matters is the applinks object, and that is the part this validator parses. Inside it, details is an array. Each entry pairs appIDs, the apps allowed to open links, with components, the URL patterns those apps handle. An app ID is your application identifier prefix (in most cases your Team ID), a dot, and the bundle identifier.

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.example.app"],
        "components": [
          {
            "/": "/products/*",
            "comment": "Open any URL whose path starts with /products/ in the app."
          },
          {
            "/": "/account/*",
            "exclude": true,
            "comment": "Keep URLs under /account/ in the browser."
          }
        ]
      }
    ]
  }
}

In this example the app ABCDE12345.com.example.app opens every URL under /products/, while /account/ stays in the browser because of exclude. The comment keys are notes for whoever reads the file. The validator confirms that applinks exists and that details has at least one entry; it does not judge the app IDs or patterns, so compare those with your Xcode project by hand. Android uses a different file: check it with the Android assetlinks.json validator.