Free apple-app-site-association & assetlinks.json Generator
Free AASA generator and assetlinks.json generator: type your Team ID, bundle ID, package name, and SHA-256 fingerprint, then download a valid universal links file for iOS and Digital Asset Links file for Android. Browser-only, no signup.
Path rules (components)
Enter a Team ID and Bundle ID to generate the file. Team IDs are 10 characters and appear under Membership details in your Apple Developer account.
Deploy checklist
- Serve at
https://example.com/.well-known/apple-app-site-association - HTTPS with a valid certificate, HTTP 200, no redirects (no 301, 302, or www rewrite)
Content-Type: application/json, no.jsonextension, file under 128 KB- Add the Associated Domains capability in Xcode with
applinks:example.com - Note: Apple's CDN fetches the file within 24 hours and devices re-check about weekly - install fresh or use
?mode=developerto test right away - Test the live file with /tools/universal-link-validator, then open a link with /tools/deep-link-tester
Quick Answer
An apple-app-site-association generator builds the JSON file iOS fetches from https://yourdomain/.well-known/apple-app-site-association to decide which app opens your links. Enter your 10-character Team ID, bundle ID, and path rules to get a valid AASA file, then switch tabs to generate the matching assetlinks.json for Android App Links. Runs in your browser, free.
Quick Facts
- Apple fetches the file from https://<domain>/.well-known/apple-app-site-association over HTTPS with no redirects and a valid certificate; the file name has no extension.
- Since iOS 14 and macOS 11, devices do not contact your server directly - Apple's associated-domains CDN fetches the file within 24 hours and devices re-check about once a week.
- The modern format uses a components array with / (path), ? (query), and # (fragment) matchers; the paths array is a legacy format that iOS 13 and later ignore when components is present.
- Wildcards: * matches any run of characters and ? matches exactly one, so "articleNumber": "????" matches a four-character value only.
- Android reads https://<domain>/.well-known/assetlinks.json, a JSON array of statements with relation delegate_permission/common.handle_all_urls and the app's SHA-256 signing certificate fingerprint.
- With Play App Signing, the fingerprint from keytool on your machine is the upload key - use the app signing key shown in Play Console or verification fails on every installed device.
- Both files must return HTTP 200 with Content-Type: application/json; a 301 to www, an HTML error page, or a text/plain header is the most common cause of links opening in the browser instead of the app.
How to generate an apple-app-site-association file and assetlinks.json
Enter app identifiers, pick path rules, download both files, deploy to /.well-known/.
- 1
Enter your domain and iOS app identifiers
Type the domain that will host the file, then your Team ID (10 uppercase letters or digits from Apple Developer > Membership) and bundle ID. The tool validates both and joins them as TEAMID.bundle.id, the appID format Apple expects.
- 2
Define which URLs open the app
Add path rules in the components format: a / pattern like /products/*, an optional ? query matcher, an optional # fragment, and an exclude toggle for URLs that should stay in Safari. Turn on the legacy paths array only if you still support iOS 12.
- 3
Add webcredentials or appclips sections
Tick webcredentials if the same domain should serve Password AutoFill and passkeys, and appclips if you ship an App Clip. The generator adds the extra top-level keys using the same app IDs.
- 4
Generate the Android assetlinks.json
Switch to the Android tab, enter the package name and one or more SHA-256 certificate fingerprints (the tool uppercases and validates the 95-character colon format), and copy the intent filter snippet with android:autoVerify="true" for your manifest.
- 5
Deploy and verify
Upload each file to /.well-known/ on your web server with Content-Type: application/json and no redirects. Then check the live URL with /tools/universal-link-validator and open a real link on a device with /tools/deep-link-tester.
What is a AASA & assetlinks.json Generator?
AASA & assetlinks.json Generator is a browser-based tool that writes the two JSON files mobile platforms use to prove a website and an app belong together: apple-app-site-association for iOS Universal Links and assetlinks.json for Android App Links. You enter identifiers and path rules; the generator emits spec-correct JSON, a download, and a deployment checklist.
The apple-app-site-association file (AASA) is what iOS reads to decide whether https://example.com/products/42 opens your app or Safari. It lives at https://example.com/.well-known/apple-app-site-association, contains an applinks section listing app IDs in TEAMID.bundle.id form and the URL components those apps handle, and may also carry webcredentials (shared passwords and passkeys), appclips, and activitycontinuation (Handoff) sections. Apple requires HTTPS, a valid certificate, no redirects, and JSON content - and since iOS 14 the file is fetched by Apple's own CDN rather than by each phone.
The Android counterpart is a Digital Asset Links statement list at https://example.com/.well-known/assetlinks.json. It is a JSON array; each statement grants a relation such as delegate_permission/common.handle_all_urls to a target identified by package name and the SHA-256 fingerprint of the certificate that signed the APK. When an intent filter in the manifest sets android:autoVerify="true", Android 6.0 and later download this file at install time and, if the fingerprint matches, route links for that host straight to the app without a disambiguation dialog.
Hand-writing either file is easy to get subtly wrong: a lowercase team ID, a fingerprint with the wrong key, a missing comma, or a paths rule that never matches because the CDN cached the previous version. This aasa generator and assetlinks.json generator validates each field as you type, shows the byte size against Apple's 128 KB limit, and pairs the output with the entitlement strings, intent filter XML, and adb commands you need on the other side of the handshake.
How does a AASA & assetlinks.json Generator work?
On the iOS tab the tool assembles an applinks.details array with one entry per app. Each entry has an appIDs array (Apple's current key; the older singular appID still works but appIDs lets one rule set cover several apps) and a components array. A component is a dictionary whose keys are the URL parts to match: "/" for the path, "?" for the query, and "#" for the fragment. The query value can be a whole-query pattern string or a dictionary of parameter names to value patterns - typing articleNumber=???? in the query field produces {"articleNumber": "????"}. Setting exclude: true tells iOS to hand that URL to Safari, and comment is ignored by the system but kept for humans.
Pattern matching in components uses two wildcards: * matches any sequence of characters including none, and ? matches exactly one character. iOS evaluates components in order and stops at the first match, so put excludes before the broad rules that would otherwise swallow them. Apple's own example lists {"#": "no_universal_links", "exclude": true} first, then "/buy/*", then an excluded "/help/website/*" ahead of the general "/help/*". The legacy paths array uses the same wildcards with a NOT prefix for exclusions, cannot express query or fragment rules, and is only consulted by iOS 12 and earlier when components is present - the generator derives it from your path rules when you enable the toggle.
On the Android tab the tool builds a statement list. Each statement is {"relation": [...], "target": {"namespace": "android_app", "package_name": ..., "sha256_cert_fingerprints": [...]}}. The relation delegate_permission/common.handle_all_urls authorises App Links; adding delegate_permission/common.get_login_creds lets the app share saved credentials with the site through Smart Lock and Credential Manager. Fingerprints are uppercased and checked against the 32-pair colon-separated hex layout that keytool -list -v prints and Play Console displays; several fingerprints in one array let a debug build and the Play-signed release both verify.
Everything runs in your browser with JSON.stringify - nothing is sent to U2L. Because both platforms cache aggressively (Apple's CDN refreshes within 24 hours and devices re-check weekly; Android 14 and lower verify only on install or update, Android 15 re-verifies periodically with up to seven days of propagation), the generator's checklist tells you to test the served file immediately with a validator and to use the ?mode=developer entitlement suffix on iOS so a development device bypasses the CDN and reads your server directly.
Use Cases
How marketers, businesses, and developers use aasa & assetlinks.json generator.
Setting up Universal Links for a new iOS app
First-time Universal Links setup needs three things to agree: the applinks:example.com entitlement in Xcode, the TEAMID.bundle.id in the AASA file, and the path rules. Generate the file here, host it at /.well-known/, and confirm with /tools/universal-link-validator before submitting to App Review. A single wrong character in the Team ID silently breaks every link.
Android App Links assetlinks with the right fingerprint
Most failed App Links come from signing the release with Play App Signing while the assetlinks.json still lists the upload key. Paste the SHA-256 from Play Console alongside your debug key so both the store build and local builds verify, then run adb shell pm get-app-links to confirm the domain shows verified.
Migrating from paths to components
Apps written for iOS 12 often carry a paths array with NOT rules and no query matching. Rebuild the rule set in components (the format iOS 13 and later prefer), keep the legacy toggle on during the transition, and drop it once your deployment target passes iOS 13 to shrink the file.
Excluding marketing and help pages from the app
Universal links should not hijack your blog, pricing, or support articles that render better on the web. Add an exclude rule such as /help/website/* ahead of the catch-all so those URLs open in Safari while /help/* with a matching articleNumber query still goes to the app.
Enabling passkeys and Password AutoFill
Password AutoFill and passkeys require a webcredentials entitlement plus a webcredentials.apps entry in the same AASA file. Tick the checkbox and the generator lists every app ID under webcredentials so iOS and macOS can offer saved credentials for your domain in the app.
Shipping an App Clip
App Clips are launched from URLs, so the domain must declare the clip's bundle ID under appclips.apps and the clip target needs an appclips:example.com entitlement (wildcard subdomains are not allowed for appclips). The generator appends .Clip to your app ID, matching Xcode's default naming.
Sharing one domain between several apps
A main app and a companion app can both claim the same host. Use Add another app to emit separate details entries with their own path rules, or list several package names in assetlinks.json. iOS matches the first app in order whose components match, so put the most specific app first.
Preparing a deep-link testing plan
Generate the files, deploy, then work through the checklist: validate the served headers, install a fresh build so the CDN entry is pulled, and open real URLs with /tools/deep-link-tester. Keep an App Store fallback ready with /tools/app-store-link-generator for users who do not have the app installed.
Smart links that respect your app files
Once verification works, a short link on your own domain can route iOS and Android users into the app and everyone else to the web page. U2L's App Links feature (see /features) builds on the same AASA and assetlinks files you generate here, so the two-file setup is the foundation for branded deep links.
AASA & assetlinks.json Generator vs Alternatives
Side-by-side feature and pricing comparison with the top alternatives.
| Feature | U2L | Branch AASA Validator | yURL | OrbitKit AASA Generator |
|---|---|---|---|---|
| Free, no signup | Free to build, paid to host | |||
| Generates the AASA file | ||||
| Generates assetlinks.json | ||||
| components with query and fragment rules | N/A | N/A | Path patterns | |
| webcredentials and appclips sections | N/A | N/A | ||
| Validates a live URL | Via /tools/universal-link-validator | |||
| Intent filter XML and adb commands | ||||
| Browser-only (no data sent) |
AASA & assetlinks.json Generator vs Branch AASA Validator and yURL
Branch's validator and yURL are testing tools: you give them a domain and they fetch the live file, check HTTPS, status code, Content-Type, and JSON validity, and yURL also fetches assetlinks.json. They are the right choice after deployment and are free without signup.
Neither writes the file for you, so a typo in appIDs or a paths rule that never matches passes their checks as long as the JSON parses. This generator produces the JSON from validated inputs, and the checklist hands you to /tools/universal-link-validator for the live-URL test, so you get both halves of the workflow.
AASA & assetlinks.json Generator vs OrbitKit AASA Generator
OrbitKit generates and hosts the AASA file on your custom domain with automatic SSL and enforces the 128 KB limit, which removes the need to configure your own web server. Building is free; live hosting is a paid subscription per app.
It covers Apple only. If you ship on both platforms you still need assetlinks.json, the intent filter, and the Play App Signing fingerprint, which this tool includes in one place. Hosting the files yourself is a five-minute task on any static host and keeps the well-known path under your control.
Best Practices
Use the appIDs array and components format
Apple's current documentation uses appIDs (plural) and components for every example. The singular appID and paths keys still parse but are legacy; new files should use the modern keys so query and fragment rules are available and the file stays readable as your routing grows.
Order excludes before catch-alls
iOS stops at the first matching component. Put {"/": "/help/website/*", "exclude": true} above {"/": "/help/*"} or the exclusion never fires. Apple's own sample places the fragment exclusion first, then narrow includes, then the broad rules.
Serve the exact headers
Return HTTP 200 with Content-Type: application/json and no redirects at both /.well-known/apple-app-site-association and /.well-known/assetlinks.json. A redirect from apex to www, a CDN HTML error page, or text/plain on the extensionless file each cause silent failure.
Publish one file per host
example.com, www.example.com, and shop.example.com are separate hosts. Apple requires an entitlement entry and an AASA file for each (or a *.example.com wildcard for non-appclips services); Android requires assetlinks.json on every host named in the intent filter.
Use the Play Console fingerprint
If Play App Signing is on, the fingerprint from keytool on your upload keystore is not what users' devices see. Copy the SHA-256 from Play Console under App integrity (the Android docs call it Release > Setup > App signing) and add the upload key as a second entry for local builds.
Test with ?mode=developer before waiting on the CDN
Add applinks:example.com?mode=developer to the entitlement on a development build so a device in developer mode fetches the file straight from your server instead of Apple's CDN. Remove it for release; production devices go through the CDN regardless.
Keep the file small and static
Apple caps the AASA at 128 KB. Thousands of individual product paths belong in a wildcard rule like /products/*, not in an enumerated list. Generate the file once, commit it to your web repo, and treat changes as deployments with a re-verification step.
Verify on both platforms after every change
Run /tools/universal-link-validator against the live URL, then on Android run adb shell pm verify-app-links --re-verify PACKAGE followed by adb shell pm get-app-links PACKAGE and look for verified next to your host. Open a real link with /tools/deep-link-tester as the final check.
Common Mistakes to Avoid
Adding a .json extension to the Apple file
The Apple file is named apple-app-site-association with no extension. Servers that infer Content-Type from extensions often return application/octet-stream for it - configure an explicit application/json mapping for that path.
Redirecting the well-known URL
Both Apple and Google reject any redirect, including http to https and apex to www. Serve the file directly at every host you declare, and exclude /.well-known/ from blanket rewrite rules.
Using the upload key fingerprint
With Play App Signing the installed APK is signed by Google's app signing key. An assetlinks.json listing only your upload key verifies nowhere except your own debug device.
Forgetting the entitlement
A perfect AASA does nothing if the app lacks com.apple.developer.associated-domains with applinks:example.com, or if the Android intent filter is missing android:autoVerify="true". Both sides must declare the relationship.
Expecting instant updates
Apple's CDN pulls the file within 24 hours and devices re-check about weekly; Android 14 and below re-read only on install or update. Reinstall the app or use developer mode instead of concluding the file is wrong.
Wildcarding the wrong thing
"/products*" matches /products and /productsale but not /products/42, while "/products/*" matches only URLs under that directory. Use ? for a fixed-length segment and check each rule against a real URL.
Technical Specifications
| iOS file | https://<host>/.well-known/apple-app-site-association (no extension), Apple limit 128 KB |
| Android file | https://<host>/.well-known/assetlinks.json - JSON array of statements |
| Required headers | HTTPS, valid certificate, HTTP 200, no redirects, Content-Type: application/json |
| AASA keys | applinks.details[].appIDs / components ({"/","?","#",exclude,comment}), optional paths; webcredentials.apps; appclips.apps; activitycontinuation.apps |
| Wildcards | * = any characters, ? = exactly one; legacy paths use NOT prefix to exclude |
| Android relations | delegate_permission/common.handle_all_urls (App Links), delegate_permission/common.get_login_creds (credential sharing) |
| Fingerprint format | SHA-256, 32 uppercase hex pairs separated by colons (95 characters) |
| Caching | Apple CDN refresh within 24 h, device re-check about weekly; Android 15+ re-verifies periodically (up to 7 days), Android 14 and lower on install/update only |
| Privacy | Generated in your browser. No identifiers or fingerprints are sent to U2L. |
Frequently Asked Questions
What is an apple-app-site-association generator?
Where does the apple-app-site-association file go?
What is the difference between paths and components?
How do wildcards work in an AASA file?
Why do my universal links still open Safari after I updated the file?
What is the mode=developer entitlement?
Do I need the webcredentials section?
How do App Clips use the AASA file?
What is an assetlinks.json generator?
How do I get the SHA-256 fingerprint for assetlinks.json?
How do I test Android App Links verification?
Why does Android verification fail with a valid file?
Can one file cover several apps?
Do I need a separate file for www and the apex domain?
Is the tool free and is my data uploaded?
Generator versus validator - which do I need?
AASA generator versus writing the JSON by hand?
How large can the apple-app-site-association file be?
Related Free Tools
Whois Lookup
Look up registrar, owner, creation date, expiry, and DNS for any domain. Free Whois data, no API key.
Free QR Code API
REST API for generating SVG and GIF QR codes. WiFi, vCard, URL, and text. Free, no API key, edge-cached.
DNS / CNAME Checker
Look up A, AAAA, CNAME, MX, TXT, NS records for any domain. Verify global DNS propagation in seconds.
SSL Certificate Checker
Inspect any SSL certificate: validity, issuer, chain, expiry, and protocol. Spot issues before users do.
HTTP Header Inspector
Inspect HTTP request and response headers for any URL. Cache, security, CORS, and server details.
URL Shortener Speed Test
Compare redirect response times across 10+ URL shorteners. Real measurements in your browser.
Key Terms
- apple-app-site-association (AASA)
- The extensionless JSON file at /.well-known/ on a domain that tells iOS, macOS, and visionOS which apps may handle the site's URLs, credentials, App Clips, and Handoff activities.
- Universal Links
- Apple's mechanism for opening a standard https URL directly in an installed app, verified through the AASA file and the applinks entitlement, with Safari as the fallback.
- assetlinks.json
- The Digital Asset Links statement list at /.well-known/assetlinks.json that authorises specific Android apps, identified by package name and signing certificate fingerprint, to handle a domain's links.
- Android App Links
- Android's verified deep links: http/https intent filters marked android:autoVerify="true" that the system checks against assetlinks.json at install so links open the app without a chooser.
- Team ID
- The 10-character application identifier prefix from your Apple Developer membership. Combined with the bundle ID as TEAMID.com.example.app it forms the appID used in the AASA file.
- SHA-256 certificate fingerprint
- A 32-byte hash of the certificate that signed an Android app, written as 32 colon-separated hex pairs. It proves to Android that the installed app is the one the website vouches for.
Turn verified app files into smart branded links
With apple-app-site-association and assetlinks.json in place, a u2l.ai short link on your domain can send iOS and Android users straight into your app and everyone else to the web page - with click analytics on every tap. Sign up free to create branded short links and QR codes that respect your deep-link setup.
Sign up free