manifest.json file that defines the plugin’s metadata, version information, and requirements. This file is essential for plugin distribution and compatibility.
Manifest Structure
The manifest is a JSON file located at the root of your plugin directory:Required Fields
These fields must be present in every manifest:id
The unique identifier for your plugin. Must be globally unique across all Obsidian plugins.- Use lowercase letters, numbers, and hyphens
- No spaces or special characters
- Should be descriptive but concise
- Must be unique in the Obsidian plugin ecosystem
calendardataviewobsidian-gittasks
name
The display name shown to users in the Community Plugins browser and settings:- Use proper capitalization
- Keep it clear and concise
- Avoid redundant terms like “Obsidian” or “Plugin”
version
The current version of your plugin, following Semantic Versioning (semver):Use Semantic Versioning:
MAJOR.MINOR.PATCH- MAJOR: Breaking changes
- MINOR: New features (backwards compatible)
- PATCH: Bug fixes (backwards compatible)
minAppVersion
The minimum Obsidian version required to run your plugin:- Use the oldest version that supports all APIs you use
- Check the API documentation for
@sincetags - Consider your target audience (desktop vs. mobile)
You can check the current Obsidian API version using the
apiVersion constant exported from the Obsidian module.description
A brief description of what your plugin does:- Keep it concise (1-2 sentences)
- Focus on the main functionality
- Avoid marketing language
- Be clear about what the plugin does
author
Your name or username:Optional Fields
These fields are optional but recommended:authorUrl
A URL to your website or profile:- Personal website
- GitHub profile
- Twitter/X profile
- Professional portfolio
fundingUrl
A URL where users can support your work:GitHub Sponsors
https://github.com/sponsors/usernameBuy Me a Coffee
https://www.buymeacoffee.com/usernamePayPal
https://paypal.me/usernamePatreon
https://www.patreon.com/usernameisDesktopOnly
Indicates whether the plugin requires desktop-only APIs:true if your plugin:
- Uses Node.js APIs (fs, path, child_process, etc.)
- Uses Electron APIs
- Interacts with the local file system directly
- Requires features not available on mobile
false or omit if your plugin:
- Uses only web APIs
- Uses only the Obsidian API
- Should work on both desktop and mobile
TypeScript Interface
The manifest structure is defined in the Obsidian API:Version Compatibility
Checking API Features
Use the@since tags in the API documentation to determine which version introduced a feature:
Supporting Multiple Versions
For maximum compatibility, check feature availability at runtime:Complete Examples
Simple Plugin
Feature-Rich Plugin
Desktop-Only Plugin
Best Practices
Unique ID
Choose a unique, descriptive ID that won’t conflict with other plugins.
Semantic Versioning
Follow semver strictly for predictable version updates.
Conservative minAppVersion
Set the minimum version as low as possible for maximum compatibility.
Clear Description
Write a concise, accurate description of your plugin’s purpose.
Test Mobile
If not desktop-only, thoroughly test on mobile before publishing.
Provide Funding
Include a funding URL to enable user support.
Validation
Obsidian validates the manifest when loading plugins. Common errors:Missing Required Field
Missing Required Field
id, name, version, minAppVersion, description, author.Invalid Version Format
Invalid Version Format
MAJOR.MINOR.PATCH (e.g., 1.0.0, 2.1.3).Invalid ID Format
Invalid ID Format
Related Resources
Plugin Lifecycle
Learn how the manifest is used during plugin loading
Obsidian Manifest Reference
Official Obsidian manifest documentation