Submission Guidelines

This guide gives new and existing publishers a comprehensive understanding of what is expected of products submitted to the Unity Asset Store. To ensure content meets a consistent standard, our team checks your incoming submissions against these guidelines during your product’s review. You will need to fix any issues mentioned in the rejection before re-submitting your product. While our review process has the best intentions of catching and informing you of all reasons why your product has been rejected, more issues may be found in your product even if your resubmission has addressed all the initial issues. In rare instances, even if your submission has gone through multiple resubmissions, some products may be deemed unfit for the Unity Asset Store.

If you have any issues regarding your submission, package, or publisher account, please open a support ticket.

1.1.a Content submitted is professionally designed and constructed. All assets are suitable for use in a development pipeline.

1.1.b Most content in submissions is developed directly by the publisher. The submission typically does not directly recreate a popular game’s design, art style and aesthetic, and is not a compilation of found content/products. The submission is not the direct result of public tutorials.

1.1.c Any asset we feel is already excessively available to our development community may be held to higher quality standards during review.

1.1.d No aspect of your product or marketing content promotes or redirects users to other marketplaces or digital stores. Any asset that directly or indirectly leverages the Unity Editor as a marketing or distribution platform is subject to the Unity Package Guiding Principles & Guidelines.

1.1.e Packages do not throw any generic errors after setup is complete. Any errors present in your product are only those that are from caught and handled exceptions.

1.1.f Assets with dependencies from Package Manager only include the necessary packages for the asset to work. Use the “Include Dependencies” feature in the Asset Store Tools to include Package Manager packages.

1.1.g Your product’s title, category, description, keywords, folders, scripts, and documentation do not contain an excessive amount of spelling or grammar issues.

1.1.h Titles, categories, keywords, folders, and file names are a relevant representation of your product.

1.1.i Titles, descriptions, keywords, documentation, and code comments are in English. Localized versions of all of these types of text in other languages can be included.

1.1.j Submissions are no more than 6GB in size.

1.1.k Submissions do not have functionality implemented to track or collect a user’s data.

1.2.a Content does not violate the Asset Store Provider Agreement or the Unity Website & Communities Additional Terms.

1.2.b Submissions do not include content that is not allowed to be resold, or not allowed to be utilized in commercial products due to its EULA. This includes content from other Asset Store products.

1.2.c Submissions do not violate any copyright protections or include content you do not hold the license to resell or redistribute.

1.2.d These assets can be incorporated into submitted products for demonstration purposes.

1.2.e If you are asked to remove third-party libraries or SDKs from your asset to avoid legal conflicts, include information on where to download the libraries/SDKs in your documentation.

1.2.f Submissions and publisher accounts do not reference unauthorized trademarked names or branded content in images, names, description text, or content/file names. Your product does not contain any brands or names that hold active trademarks. Titles do not start with a brand name or infer an affiliation with a brand. For example, "Tools for Unity" is acceptable but "Unity Tools" is not.

1.2.g References to the Unity brand adhere to our trademark guidelines.

1.2.h Content published on the Asset Store is provided under the Asset Store EULA. Products are not sold under any unique licensing, unless previously agreed upon.

1.2.i Submissions of perpetually free products that you have developed and provide open-sourced through other sites can include a compatible license such as MIT, BSD 3-Clause, or Apache. Submissions do not contain licenses that require a product to maintain open-sourced or limited usability in commercial products such as GNU/GPL Mozilla Public License, or any Creative Commons/Apache 2.0 that requires attribution.

1.2.j Fonts, audio, and other third-party components with dependent licenses included in your submission are compatible with our EULA and include a license file detailing the component that it is covering. A Third-Party Notices text file is also included in the package and provides clear guidance on which components are under the appropriate license. The product description on the Asset Store also contains a notice stating the third-party software licensing included in the package. For example:

"Asset uses [name of component] under [name of license]; see Third-Party Notices.txt file in package for details."

1.3.a Your asset will be tested on the most recent publicly available version of Unity and is required to meet all of our standards in that version of Unity or whichever version(s) your content is explicitly stated to be intended for.

1.3.b The version of Unity used to upload your package determines the Unity version needed by customers to import your asset. New assets must use Unity version 2019.4.0 LTS or newer.

1.3.c If you are unable to make your package compatible across Unity versions, upload your package using multiple versions of Unity. You may also provide reasoning why an asset is not compatible with a specific version of Unity within the description text. For example:

“Due to a bug in Unity 2019.3, [this asset or aspect of the asset] will not work.”

1.3.d Packages are not submitted exclusively with beta versions of Unity unless they are specifically designed around features in that specific Unity beta version. Beta versions of Unity are explicitly stated in the package’s description.

1.3.e Packages submitted with any beta version of Unity are required to be resubmitted when a beta or release candidate is officially published to accommodate any changes or fixes.

1.4.a Submissions do not include any digital rights management (DRM), time restrictions, or functionality that restricts users from directly using content or features to their full extent.

1.4.b Submissions do not require a user to register, sign up, or pay extra costs for a package to fully function.

1.4.c Packages do not include watermarks or otherwise obstruct the use of the product.

1.4.d Submissions do not have any artificial limits implemented on functionality or usability. To familiarize users with your product, you may provide a "lite" (smaller/cheaper/indie/free) version of your package. Lite and free versions do not have limitations implemented on the functionality of your product’s features. Lite packages only have a reduced set of features compared to your full product.

1.5.a Until further notice, the Asset Store is not accepting any submissions that include executables.

1.5.b If you are an online service such as a monetization service, ad-network, back-end hosting service, analytics system, or other service where a variable amount of money changes hands after the user downloads your SDK or plugin, register your product as an Asset Store Service for it to be distributed on the Unity Asset Store. To register, complete this form and wait to be contacted by a Unity representative. Service submissions do not include non-proprietary content unless non-proprietary content is a registered Asset Store Service or is under an open-source license supported by Unity.

2.1.a Packages are nested under a folder with either your publisher name or package name as the title. Exceptions include assets in the folders outlined in the Special Folders and Script Compilation Order documentation (for example, "Gizmos" or "Editor Default Resources").

2.1.b Assets are sorted into folders. Folders are named depending on the type of assets they contain. For example, “Mesh”, “Script”, or “Material”. Packages do not have a range of file types included under a singular folder.

2.1.c Packages do not contain any duplicate, unused, or redundant files.

2.1.d Content is not included in any folder named "AssetStoreTools" or any variation of that name as that folder is automatically stripped when your content is uploaded.

2.1.e Any incremental files are appropriately named with proper number padding. For example, "asset01" if you have over 10 assets, instead of "asset1".

2.1.f File names are not excessively lengthened with descriptors such as "High Quality", "Low Poly", or "PBR". All details about your product are contained in the description text or keywords. File paths for assets are under 140 characters.

2.2.a Submissions do not contain .unitypackage files that obscure or compress content.

2.2.b Submissions that include setup preferences, settings, or supplemental files for another Asset Store product are nested in a .unitypackage file.

2.2.c Submissions that include alternative render pipeline content may be nested in a .unitypackage file.

2.2.d Submissions only include .zip or .rar files if they are compressing files that do not natively function in the Unity editor. (For example, Blender, HTML Documentation, or Visual Studio Projects.)

2.3.a Usable documentation is provided locally if your product requires setup and usage information. This local documentation includes links to any additional online documentation. More extensive documentation of your product may be found online, within in-Editor-tutorials, inline documentation with commented code, or tooltips.

2.3.b Documentation files are .txt, .pdf, .html, .md, or .rtf file types.

2.3.c Documentation includes a support email for users to contact you.

2.3.d Video documentation or tutorials are available online (for example, YouTube or Vimeo) and not included in your product. The product’s documentation includes a link to these videos.

2.3.e Shader documentation fully describes each shader property.

2.3.f Documentation for server-based plugins (for example, PHP or SQL) assumes users have a basic understanding of server hosting and setup. Your documentation only describes how to set up and use your plugin.

2.4.a Mesh assets are either .fbx, .abc, or .obj files.

2.4.b All visible meshes have a paired set of textures and materials assigned to them. A corresponding prefab is also set up with all variations of the texture/mesh/material. Submissions do not contain untextured meshes solely for prototyping purposes.

2.4.c Large environments or scenes are broken up into individual meshes. Submissions do not include entire environments as one object.

2.4.d Prefabs have their position/rotation set to zero upon import, and their scale set to 1.

2.4.e Meshes are at a 1 unit : 1 meter scale.

2.4.f All meshes have a local pivot point positioned at the bottom center of the object, in the same corner of any modular objects, or where the object would logically pivot/rotate/animate. Meshes are rotated to have their positive Z axis facing forward.

2.4.g Before submission, photoscanned data is retopologized and optimized to a state that users can edit if needed. Submissions do not include meshes that are the direct result of scans.

2.4.h Assets do not have an unreasonably excessive mesh density.

2.4.i Static mesh prefabs which represent solid objects are set up with a collider component that fits your mesh.

2.4.j Base characters or avatars that are completely nude are marketed and presented in a neutral pose and rendered in a realistic style for medical or educational purposes.

2.4.k Models or images do not contain genitalia.

2.4.1.a Character models are weighted to an accompanying rig. The rig is either set up with Unity’s Mecanim system or includes your own animations.

2.4.1.b When set to animations, rigs do not show any obvious creases or unusual deformations.

2.4.1.c Bipedal animations are ready to use with Unity’s default “Humanoid” avatar.

2.4.1.d Assets of non-bipedal animations include a demonstration mesh with a fully documented rig breakdown so that users can create meshes designed for the animations.

2.4.1.e Animations are sliced and named prior to submission so that submissions do not contain a single, long animation clip.

2.4.1.f Submissions do not include raw motion capture (mocap) data. Animations developed from mocap data comprise sliced and usable animations.

2.4.1.g Animations have fluid movement without any jarring transitions.

2.4.1.h Animation asset submissions have a video demonstration in their marketing material, showcasing the included animations.

2.4.1.i Animations for unique characters are contained in their own prefab.

2.4.2.a Sprite sheets are imported with the “Sprite” import settings, correctly sliced and named.

2.4.2.b Sprite animations are spliced, named, and set up as proper clips.

2.4.2.c Particle systems are saved as prefabs.

2.4.3.a Submissions do not include .jpeg files. Image files are in a lossless compression format such as .png, .tga, or .psd. Exceptions are assets in the Tools, Add-Ons, Audio, and Templates categories.

2.4.3.b Packages using physically based rendering (PBR) include at least an albedo, normal, metallic (or specular), and smoothness texture map. For more information, see our learn page on PBR in Unity.

2.4.3.c Tileable textures tile without any seams or obvious edges.

2.4.3.d Maps with an alpha channel are paired with a material that can read that channel.

2.4.3.e Your product does not contain any imported materials that aren’t being used.

2.4.3.f Normal maps are marked as a “Normal Map” in the import settings.

2.4.3.g Assets do not have an excessive number of materials assigned to them.

2.4.3.h .sbsar files and other procedural materials have documentation or a demo scene showcasing their parameters.

2.4.3.i Dimensions of textures have pixel counts that are a power of 2 when appropriate.

2.4.3.j Materials include all appropriate textures and are properly set up.

2.4.3.k Submissions of GUI packs include a functional demonstration scene showcasing the components being used.

2.4.3.l GUI components have their elements separated and named either before import or through Unity Editor’s sprite editor settings.

2.5.a Scripts include namespaces within which all named entities and identifiers are declared.

2.5.b Assets that support Android builds target 64-bit architecture.

2.5.c Submission does not contain Javascript files.

2.5.1.a Editor extension file menus are placed under an existing menu. If no existing menus are a good fit, it is placed under a custom menu called "Tools". This keeps the Editor clean and organized.

2.5.1.b Undo operations are supported. Refer to the Unity documentation for information about Undo support.

2.5.1.c Unique windows are for practical support or informative purposes.

2.5.1.d Submissions that utilize a server-based plugin automatically populate any new databases with necessary tables.

2.6.a Essentials and Template Projects are designed as instructional, tutorial, or framework products.

2.6.b Essentials and Template Projects have visual content or functionality displayed in a demo scene.

2.6.c Documentation explains more than just how to run the project. It includes in-depth information about how the project is designed and how users can edit and expand on your project.

2.6.d The Project Settings of your product are automatically included with any submission uploaded to the “Complete Projects,” or “Templates” category or subcategories. Users will receive a notification that their Project Settings will be replaced when importing your product.

2.7.a All audio asset submissions link to a preview web server or service such as SoundCloud™.

2.7.b Audio files are normalized.

2.7.c Audio files use a lossless format such as .wav. Submissions do not contain .mp3 or .ogg files. For more information on supported formats, see Unity's documentation about Audio files.

3.1.a Titles are unique from any other live package on the Asset Store.

3.2.a Description text accurately covers all important aspects or key features of your product including dependencies or other requirements for use of the asset.

3.2.b Description text for art assets lists the number of unique assets or asset types included in your product. Detailed information such as the average polygon count, texture/sprite dimensions, and types of texture maps included for each asset is also provided.

3.2.c All description text is formatted properly with .html tags. The product description is not a single block of text. Use these formatting tags to make the description easy to read and understand:

Line break

<br>

Text

<a href="website">

Hyperlinks

</a>

Bold

<strong></strong>

Italics

<em></em>

3.2.d Hyperlinks are relevant and lead to active, non-malicious sites and not direct downloads. Hyperlinks do not include a redirect link.

3.2.e Description text only relates to the content of the package. It does not promote any other products unless they are an extension of your product, directly compatible with your product, or required for your product to function.

3.2.f Submissions do not promote any “special offers” (free tutorial, free guidebooks, try before you buy, etc)

3.3.a Marketing images do not have plain text or excessive description text. You may use text in the image for publisher name, asset title, brand logo, and tagline.

3.3.b Marketing images do not include any sale related graphics, banners, or attempts to recreate any official Asset Store sale promotional graphics.

4.1.a Publisher information includes: profile picture, publisher name, website, promo media, promo paragraph, customer support contact, and customer support website.

4.1.b Publishers have an actively maintained website that shows relevant work and skill sets.

4.1.c Publisher website pages do not include redirect links.

4.2.a The price you set on the Asset Store should be comparable to your pricing for similar products on other stores and marketplaces.

4.2.b Personal sales do not last longer than two weeks.

4.2.c Sale periods are separated by at least two months.

4.2.d Details of a personal sale are provided in your description text. Sale period and regular price are clearly stated.

4.2.e Your product is not promoted as being included in any sales or features hosted by Unity Technologies that you are not actually included in.

4.2.f To be considered for an official Unity organized sale, your package must maintain a consistent price for two months. A price increase due to a large update will not disqualify you from being included in a sale.

4.2.g After being included in an official sale, your package’s price is not reduced for six weeks.

4.2.h New assets may begin on sale for the first two weeks of launch if this sale is stated in the product description with the regular price listed.