01
Start with the embedded profile
Extract embedded.mobileprovision from your own app bundle before comparing profiles. The example is synthetic CMS content with no signer, useful for exploring the views but impossible to install.
iOS / Android Dev Tools
Provisioning profile viewerInspect the XML inside
Choose a local profile or try the synthetic example. Decode the file, then inspect its fields and export an XML copy.
Provisioning profile viewer
Profile file
Drop one .mobileprovision or .provisionprofile file here. Maximum 5 MiB.
No file selected
Result
Reading stays in this tab. Files are not uploaded or saved by the tool.
Options
Mask known device strings and empty binary data. Team, app and other metadata remain visible. Changing this option requires decoding again.
Choose a file, then decode.
Decoding does not verify signatures, certificates, revocation or installation eligibility.
Export is an unsigned XML copy, not an installable provisioning profile.
A provisioning profile viewer helps when an archive uses an unexpected team, a device cannot install a development build, or two similarly named profiles have different dates. Inspect the file that was actually embedded in the app before comparing it with a downloaded copy.
This mobileprovision decoder follows the CMS container to its embedded XML. You can inspect provisioning profile fields without treating a readable document as proof of an Apple signature. The XML is a diagnostic view; modern systems can use the separate DER-Encoded-Profile representation.
Why use this provisioning profile viewer?
Keep the overview and evidence together
This provisioning profile viewer puts the team, application identifier and profile expiration date in an overview, with the original field paths one view away. Entitlements remain typed values, so a boolean permission does not become an ambiguous text label.
Apply device masking to exported copies
Device identifiers are hidden by default in the tree, entitlements and XML copy. Matching strings are replaced, and binary data is omitted because it can carry another copy of the identifiers. Team and app metadata remain visible; this is selective masking, not anonymization.
Read the file that shipped
02
Change masking, then decode again
Turning device masking on or off clears the previous result and disables export. Click Decode again, or use Ctrl/Cmd + Enter. Switching between overview, entitlements, tree and XML does not change the parsed data.
03
Expand only the branch you need
Click a dictionary or array path to collapse or expand its descendants. The tree adds 50 rows at a time; export still includes the complete current XML copy. Clear and replacement previews can be undone once.
Find the field behind the failure
Team and application identity
See the profile name, UUID, team name and TeamIdentifier values. The displayed Bundle ID is derived by removing the first prefix segment from application-identifier, with the macOS entitlement key as a fallback. Wildcards remain intact.
Typed entitlements
Inspect the Entitlements dictionary separately from the full document. Arrays, dictionaries, booleans, integers, dates and data keep their types. These values describe the profile’s permission allowance; they are not a dump of the app’s actual signed entitlements.
Dates with a comparison time
CreationDate and ExpirationDate remain UTC values. The overview reports whether the expiration instant has passed according to the browser clock at decode time. A missing date stays unknown, and a future date never establishes signature validity.
A usable XML extraction
Extract plist content through the SignedData structure instead of searching arbitrary bytes for XML tags. The downloaded plist keeps value types and dictionary order. With masking enabled, device strings are substituted and all data payloads become empty data elements.
What decoding does and does not establish
- No signature or installation verdict
- The reader does not verify CMS signatures, the certificate chain, revocation, Apple trust or whether a device can install the app. A container with zero signer entries is identified explicitly. Decode success only describes the supported content structure.
- XML is a diagnostic view
- Apple’s modern systems can use DER-Encoded-Profile as their source of truth. This tool does not decode that inner representation or compare it with the XML. Unknown XML fields remain inspectable without assigning them invented meanings or inferring a distribution type.
- A specific input format
- Use one binary CMS SignedData file containing an embedded UTF-8 XML plist. Definite and indefinite BER containers and constructed octet strings are supported. Detached or encrypted CMS, raw XML and binary plists are rejected; IPA, P12 and URL inputs are outside this tool.
- Masking has a defined scope
- The default output replaces known ProvisionedDevices identifiers wherever they recur in string values or keys and empties binary data. Names, teams, Bundle IDs and other metadata remain. Review the content before sharing; disable masking and decode again when you need the complete original values.
- Bounded reading, unsigned output
- Files are limited to 5 MiB, with 10,000 nodes and 64 levels in each parser, plus a 10 MiB serialized output budget. Duplicate plist keys and malformed values are rejected. Export removes the CMS envelope and cannot renew, sign or install a profile.
Provisioning profile viewer FAQ
How do I open a .mobileprovision file?
Choose the local file and press Decode. The reader checks the CMS structure and then parses the enclosed XML plist. A text editor may show readable fragments, but those fragments alone do not establish that the surrounding file is a supported container.
How can I check which device UDIDs a build includes?
Open the full tree and expand ProvisionedDevices. Masking initially replaces the identifiers while retaining the list count. To inspect their actual values, disable masking and decode again. An absent list does not automatically mean that every device is allowed.
Can the command line tell whether a provisioning profile is still valid?
Read ExpirationDate and the comparison time in the overview. This answers whether the listed date has passed on your current clock. It does not answer whether the signature, certificate or profile is currently accepted by Apple; use platform signing tools for that determination.
Which provisioning profile was used to build an IPA?
For a development or ad hoc IPA, inspect the embedded.mobileprovision inside the app bundle in Payload after extracting the archive yourself. This page does not unpack IPA files. Apps delivered by the App Store may not contain an embedded provisioning profile.
Can I set a provisioning profile’s expiration date?
Editing an exported XML date cannot extend an Apple-signed profile. The XML copy has no CMS signature and is for inspection only. Update or regenerate the profile through your developer account or Xcode as appropriate, then build again using the replacement.
Missing a detail about profile inspection?
Inspect the next signing mismatch
Use the provisioning profile viewer to compare the actual team, device list and entitlements behind a build. Keep the unsigned XML copy as debugging evidence, and use Apple’s tools when you need a trust or signing decision.