Mobileconfig Validator

Run a local mobileconfig static preflight

This tool checks unsigned XML property lists without uploading the source profile. It reports malformed structure, missing profile metadata, duplicate identifiers, and known payload values that disagree with a pinned snapshot of Apple’s Device Management schema. Choose the target platform and OS version, review evidence for every finding, and correct the original profile in the system that generated it.

The result is deliberately narrower than an installation verdict. A clean report cannot prove certificate trust, MDM server behavior, enrollment requirements, hardware state, or the behavior of a particular OS build. Unknown vendor payloads and keys are marked unverified instead of being incorrectly rejected.

What this mobileconfig validator checks

Apple configuration profiles contain a top-level configuration dictionary and one or more payload dictionaries. A file can be valid XML yet still use the wrong data type, omit a required key, repeat a UUID, or select a value outside a documented list. Static preflight catches those deterministic problems early and gives an exact path back to the field.

Checks include plist structure; profile and payload type, version, identifier, and UUID metadata; duplicate identifiers and UUIDs; known required fields; boolean, string, integer, real, array, dictionary, data, and date types; documented value lists and numeric ranges; and introduced or removed OS versions. Payloads absent from the pinned schema remain visible but unverified.

What static profile validation cannot prove

This website is not Apple certification and is not affiliated with Apple. It does not communicate with devices or MDM servers. It does not establish a CMS signer’s identity, certificate path, revocation status, or authorization. It cannot verify encrypted profiles, supervision state, account credentials, network reachability, certificate enrollment, payload interactions, or vendor-specific deployment logic.

Use sanitized profiles whenever possible. Even though the browser does not upload the file, a profile may contain network passwords, certificate material, usernames, internal URLs, and organization identifiers. Keep the original secure, review the generated report before sharing it, and run final tests in a controlled environment.

How local profile validation works

The browser reads the selected file into memory under a strict size limit, rejects external entity declarations, parses the plist, and walks each payload. Known fields are compared with rules compiled from a fixed Apple schema commit so that the rule source is repeatable. Unknown schema coverage becomes a warning, not a false pass or false failure.

After correcting a profile, run the check again, then use a staging MDM or disposable test device. Preserve signing checks, change approval, deployment scope, device targeting, and rollback as separate production controls. Reload this page to clear the in-memory profile.

Mobileconfig validator FAQ

Does a clean report prove that the profile will install?

No. It only means that implemented static checks found no error. Apple software, an MDM, certificate trust, enrollment mode, device state, and the target OS build can still reject it.

What happens to an unknown key?

The key is reported as unverified. Third-party vendors can add extensions and Apple’s public schema can lag a release, so unknown fields must not be treated as automatic errors.

Are signed and encrypted files supported?

They are not treated as ordinary XML. If the content cannot be safely parsed without implying signer trust or decryption, the result is unverified rather than a misleading pass.