Drop a .mobileprovision to inspect team ID, expiry, provisioned devices, and entitlements — entirely in your browser. Nothing is uploaded.
Parsed locally with JavaScript. Nothing is uploaded, logged, or stored on a server.
See exactly when the profile expires and whether it's still valid for signing or installation.
For Development and Ad Hoc profiles, search and copy the full UDID list with one click.
A .mobileprovision file is a PKCS #7 signed container wrapping an XML property list. That plist ties one App ID to a set of signing certificates, a list of device UDIDs and a set of entitlements, and stamps the whole thing with an expiry date. Decoding the profile shows all of it: which app it covers, which Apple Developer team issued it, which certificates may sign with it, which devices it installs on, what the app is permitted to do, and the day it stops working.
Two decoded fields separate them. Development and ad hoc profiles both contain a ProvisionedDevices list; App Store profiles contain none. What tells those two apart is the get-task-allow entitlement: it is true on a development profile, because Xcode needs to attach a debugger, and false on an ad hoc profile. Enterprise in-house profiles also have no device list, but they carry ProvisionsAllDevices set to true.
One year for a paid Apple Developer Program team, and seven days for a free personal team — the decoder shows the issued lifetime as TimeToLive. The signing certificate runs on its own clock: Apple development certificates last one year and distribution certificates three, and a profile stops working the moment the certificate it lists expires or is revoked. Whichever date comes first ends the build's life.
An expired profile is one of the most common causes of a build that suddenly will not install. Ad hoc and enterprise builds carry their profile inside the app bundle, so once the expiry date passes iOS refuses to install the .ipa and a copy already on a device stops launching. App Store builds are re-signed by Apple during distribution, so an expired App Store profile blocks your next upload rather than apps already published. Checking the expiry date before you cut a release is a cheap habit.
Yes. Development and ad hoc profiles list every registered UDID in the ProvisionedDevices array, and the decoder shows the full list with a filter box and a copy-all option. Enterprise profiles use ProvisionsAllDevices instead of a list, and App Store profiles contain no devices at all. If a tester's UDID is not in the list the build will not install on their device. Registering the device in the Apple Developer portal is not enough on its own: you also have to regenerate the profile and rebuild with it.
Rename the .ipa to .zip, unzip it, and look inside Payload/YourApp.app/ for embedded.mobileprovision. Drop that file straight into the decoder. The IPA inspector does the same job without unzipping: it reads the embedded profile out of the .ipa alongside the bundle ID, version and entitlements.
No. The file is parsed locally in your browser with JavaScript and never leaves your machine. That matters because a profile identifies your Apple Developer team and lists your registered device UDIDs. It holds no private key (signing keys live in your keychain, not in the profile), but it is still account metadata you have no reason to hand to a website.
A .mobileprovision file is a PKCS #7 signed container wrapping a single XML property list. That plist is the part worth reading: it ties one App ID to a set of signing certificates, a set of device UDIDs and a set of entitlements, and stamps the whole bundle with an expiry date. Decoding a profile answers five questions at once: which app, signed by whom, installable on which devices, permitted to do what, until when.
Apple's signature wraps the plist so it cannot be edited after issue. The decoder above lifts the plist out of that envelope and renders it, without checking the signature over it. It is a viewer, not a validator. It will happily show you a profile that is expired, or issued to a team you have never heard of, which is usually the thing you were trying to find out.
| Key in the decoded plist | What it tells you |
|---|---|
| Name | The label Xcode and the Apple Developer portal show. Cosmetic: it proves nothing about the contents. |
| UUID | The profile's identity. This is the value a build setting or a fastlane config points at. |
| AppIDName / application-identifier | The bundle ID the profile covers. A trailing * means a wildcard App ID, which cannot carry push or App Groups. |
| TeamName / TeamIdentifier | Which Apple Developer account issued it. Worth checking on any profile someone else sent you. |
| DeveloperCertificates | The signing certificates this profile trusts, as raw DER. A build signed with anything else is rejected. |
| ProvisionedDevices | The UDID allow-list. Present on development and ad hoc profiles, absent on App Store profiles. |
| ProvisionsAllDevices | Present and true only on Enterprise in-house profiles, which install on any device. |
| Entitlements | What the app is permitted to do: push, App Groups, keychain sharing, associated domains, and get-task-allow. |
| CreationDate / ExpirationDate | The profile's life span. The expiry is the field most worth looking at before a release. |
| TimeToLive | How many days the profile was issued for. It reads 7 on a free personal team, 365 on a paid one. |
| IsXcodeManaged | Whether Xcode's Automatically manage signing created the profile rather than a person in the portal. |
Three profile types cover nearly every build, and the decoded fields separate them cleanly. The pair people confuse is development and ad hoc, because both list devices. The difference between them is a single entitlement.
| Profile type | ProvisionedDevices | get-task-allow | ProvisionsAllDevices | Used for |
|---|---|---|---|---|
| Development | Yes | true | No | Running and debugging from Xcode on your own registered devices |
| Ad Hoc | Yes | false | No | Beta builds installed directly on the devices listed in the profile |
| App Store | No | false | No | Uploads to App Store Connect, including TestFlight |
| Enterprise (in-house) | No | false | true | Internal-only distribution under the Apple Developer Enterprise Program |
get-task-allow is the entitlement that lets a debugger attach to the running process. Xcode needs it; a build you hand to someone else must not have it. So a profile with a device list and get-task-allow = true is a development profile, and the same profile with false is an ad hoc one. When ProvisionedDevices is missing altogether there is no per-device allow-list at all: either Apple re-signs and distributes the app (App Store), or the profile carries ProvisionsAllDevices and installs anywhere (enterprise in-house).
A secondary tell: App Store profiles normally also carry beta-reports-active, the entitlement TestFlight uses for crash and feedback reporting. If you see it, you are holding a profile meant for App Store Connect, not one you can install over the air. The decoder badges the type for you using exactly the rules in the table above. Knowing the fields yourself matters the day somebody sends you a profile and tells you it is ad hoc.
Profiles expire, and an expired profile is one of the most common reasons a build that installed fine last month will not install today. A profile issued to a paid Apple Developer Program team is valid for one year. A profile issued to a free personal team is valid for seven days. The decoder shows that as TimeToLive: 7.
What breaks depends on the profile type. Ad hoc and enterprise builds carry their profile inside the app bundle as embedded.mobileprovision, so the clock runs on the tester's device: once the date passes iOS refuses to install the build, and a copy already installed stops launching. App Store builds are re-signed by Apple during distribution, so an expired App Store profile blocks your next upload rather than apps already published.
The certificate runs on a separate clock. Apple development certificates are valid for one year and distribution certificates for three, and a profile stops working the moment a certificate it lists expires or is revoked. Whichever date arrives first ends the build's life, which is why “it worked in January” is not evidence of anything in December.
Make it a pre-release habit
Decode the profile before you cut a build, not after a tester reports a failed install. If the expiry is inside 7 days, regenerate the profile in the Apple Developer portal and rebuild first. A profile regenerated afterwards does nothing for the copies people already have, and you end up chasing every tester to reinstall. The decoder shows a days-remaining count for exactly this reason.
For development and ad hoc profiles, ProvisionedDevices is the allow-list: if a tester's UDID is not in it, iOS will not install the build on their phone, and re-sending the link will not change that. Older devices have a 40-character hexadecimal UDID; devices from iPhone XS / A12 onwards (2018) use a 25-character form with a dash after the first eight characters. Both appear verbatim in the decoded list.
The practical loop is short: collect the identifier with the iPhone and iPad UDID checker, match it against the decoded ProvisionedDevices list, and only then decide whether you need to regenerate anything. Most “the link is broken” reports from testers are really a missing UDID.
~/Library/Developer/Xcode/UserData/Provisioning Profiles/ on Xcode 16 and later, and in ~/Library/MobileDevice/Provisioning Profiles/ on earlier versions..ipa to .zip, unzip it, and open Payload/YourApp.app/embedded.mobileprovision. Or skip the unzipping. The IPA inspector reads the embedded profile straight out of the archive, next to the bundle ID, version and entitlements..provisionprofile extension. The decoder accepts both.security cms -D -i profile.mobileprovision prints the same plist. The decoder is the equivalent on Windows or Linux, or when the file arrived by email and you would rather not shell out.The DeveloperCertificates array holds the certificates the profile trusts, stored as raw DER. The decoder shows how many there are and lets you copy each one as Base64. It does not parse the certificate itself. To read a certificate's own subject and expiry, save the copied Base64 as cert.b64 and run:
openssl base64 -d -in cert.b64 | openssl x509 -inform der -noout -subject -enddate
A provisioning profile contains only public certificates — never a private key. Any site asking you to upload a .p12 is asking for something else entirely, which is the subject of our note on why you should not sign an IPA online.
Most signing and install failures are a mismatch between what the profile grants and what the build or the device needs. Each of these has a field to look at first.
| Symptom | What to check in the decoded profile |
|---|---|
| “Unable to install” on a tester's iPhone | Is their UDID in ProvisionedDevices, and is ExpirationDate still in the future? |
| App installs, then crashes on launch | Do the Entitlements cover what the binary asks for? A wildcard App ID cannot carry push or App Groups. |
| “Valid signing identity not found” | Is the certificate you are signing with one of the DeveloperCertificates entries, and is it in your keychain? |
| Build installs but the debugger will not attach | get-task-allow is false, so this is a distribution profile, not a development one. |
| Xcode ignores the profile you expected | Compare UUID against the profile your build settings or fastlane configuration reference. |
A valid profile with the right devices on it still leaves the last mile: getting the signed build onto a phone. BetaDrop takes a signed .ipa and returns an over-the-air install link and a QR code, generating the itms-services manifest iOS expects, so a tester installs straight from Safari. No TestFlight review wait, no tester account. Signing stays on your machine; we never ask for a certificate or a key.
Further reading: iOS provisioning profiles explained covers the same ground from the Apple Developer portal side, including the “profile missing” error and manual signing on CI.
