Guidelines

Submission guidelines

Plug-in assets must work. If the asset does not run or otherwise does not work in the specified Godot version then it will be rejected. Any shared library files listed in a .gdextension file must be present.
The license needs to correctly match your Asset Store listing and must accompany the downloaded asset. This file must contain the license text itself and a copyright statement that includes the year(s) and copyright holder.
Use proper English for the name, summary, and description of your asset. This includes using correct capitalization and full sentences in the description. You can also include other languages but there should at least be an English version.
Descriptions cannot just be a URL to your repository.
Plug-in assets must follow the addons/asset_name/ folder structure. Doing so avoids having files clash with other assets and allows for clean installation of the asset.
An icon thumbnail must be included in your Asset Store listing and must be 16:9 aspect ratio.
Tags cannot be your asset's name as that can just be searched.
Check to see if a singular or plural form of your tag already exists, if so do not add the opposite form. For example, if the tag "tools" exists, do not add "tool".
The following types of submissions will be rejected:
- Any low-effort and/or joke submissions
- NuGet files
- Standalone, compiled executables
- Otherwise empty zips contains just instruction documents

Make sure to check for and remove unnecessary files like .gitignore, .gitattributes, .github folders, etc. from your asset ZIP.
- Windows users should be on the lookout for Thumbs.db files which will bloat downloads.
- macOS users should also be on the lookout for .DS_Store files and __MACOSX folders which will bloat downloads.
Fix or suppress all script warnings. The warning system is there to help identify issues with your code, but people using your asset don't need to see them.
Make your code conform to the official style guides. Having a consistent style helps other people read your code, and it also helps if other people wish to contribute to your asset.
If your asset is a library for working with other files, consider including example files in the asset.
If your asset has a repository, consider using a proper .gitignore file. It's important to keep redundant data out of the repository. Here's a template.
If your asset has a repository, consider a .gitattributes file. This file allows giving extra instructions to Git, such as specifying line endings and listing files not required for your asset to function with the export-ignore directive. If you are downloading your asset from places like GitHub, it will be easier to upload a clean copy to the Asset Store.

Thumbnails must accurately represent the asset.
Do not depict content, features, interfaces, or results that the asset does not include or cannot produce.
For tools and plug-ins, use a clear screenshot of the main feature or a simple, recognizable icon.
Avoid crowded collages, excessive effects, and busy backgrounds.
Check that the thumbnail remains recognizable at small sizes. Any added text should be easy to read.
Crop screenshots to highlight the relevant content. Avoid showing the entire editor when only a small part demonstrates the asset.

Thumbnails will be rejected if:

Unrelated artwork used primarily to attract attention.
Images that imply higher visual quality, additional content, or functionality that the asset does not provide.
Fabricated screenshots or interfaces presented as actual examples of the asset.
Thumbnails dominated by text, including long descriptions, feature lists, or promotional slogans.
Images too cluttered, distorted, or low-resolution to identify what they represent.