Updated August 22nd, 2026

Items offered on Wrapmarket must be complete, functional, professionally presented, and ready for customers to use. The Quality Guidelines describe the standards considered when reviewing new items and the continuing expectations that apply after an item is published.

Quality is evaluated in the context of the item. Different types of items may require different files, documentation, previews, technical preparation, and levels of detail. Meeting the technical requirements of the submission form does not by itself guarantee that an item meets the overall quality standard.

Wrapmarket may decide to make minor changes or corrections to a listing during review or after publication to improve its presentation quality, consistency, or accuracy. Changes that materially affect how the item is represented may instead be requested from the creator.

In these guidelines, must, must not, and direct instructions identify requirements. The terms should and should not describe the normal expectation unless a different approach is appropriate for the item and produces an equally complete, usable, and professional result.

Wrapmarket may update these guidelines as marketplace needs, technology, and customer expectations change.


Table of contents


Preparing the item for sale on Wrapmarket

This section explains how an item and its customer-facing materials must be prepared for sale on Wrapmarket. It covers external platform references, official Wrapmarket policies, and permitted links.

All customer-facing materials must be prepared for Wrapmarket or use platform-neutral language. Do not include branding, account instructions, purchase or download instructions, licensing terms, or support instructions from another platform.

Advertising and promotional material

This section applies to the item listing, thumbnail, screenshots, live preview, documentation, download package, and other submitted or included materials.

Advertising

  • Do not use any part of the submission to direct customers to purchase this or another item outside Wrapmarket or to advertise items that are not available on Wrapmarket. Links to the creator's Wrapmarket shop and other items available on Wrapmarket are encouraged.
  • External links may be included when required by a category-specific delivery method described in these guidelines or when reasonably necessary for technical documentation, required dependencies, attribution, third-party license information, or a support channel permitted under the Support Policy. These links must not direct customers to an external purchase or promotional experience.
  • Items may demonstrate advertising functionality using clearly fictional placeholder content, but they must not be configured to generate revenue for the creator or track Wrapmarket customers. Customer-facing materials must not serve paid advertisements, affiliate promotions, sponsored content, or other live third-party advertising.

Promotional material

Promotional claims must be accurate, supportable, current, relevant to the item, and consistent with the information available to customers on Wrapmarket.

  • Do not imply official status or endorsement, or use vague or absolute promotional claims about the item as a whole. Terms such as premium, best, perfect, ultimate, unlimited, complete, or guaranteed may be used only when they describe a specific, verifiable characteristic.
  • Do not include marketplace rank, the current item price, discount amount, sale badge, sale deadline, promotions, sales or customer count, or similar information that may become inaccurate or conflict with the listing.
  • Do not present fabricated or unverifiable information such as ratings, reviews, testimonials, awards, certifications, partnerships, endorsements, claims of popularity or superiority, or similar claims as factual, including information that originates from another platform.

Representing Wrapmarket policies

Do not create or include separate customer license, support, refund, or update terms. Link to the official Wrapmarket policies when this information is necessary.

Restrictions

  • Do not include creator-authored or external platform license terms that claim to govern the customer's use of the item. This does not prevent creators from including applicable third-party license and attribution notices, which should be clearly identified as applying only to those materials.
  • Do not make separate promises of free or unrestricted support, guaranteed refunds, no refunds, or other terms that conflict with these policies. Do not make separate promises of free or lifetime updates. Access to item releases is determined by the support period associated with each license.

Exclusivity

See also: Commission Structure

Violation of the exclusivity requirements may result in restriction from the ability to sell items exclusively and earnings corrections for past purchases.

Exclusivity applies to the implementation of the design submitted to Wrapmarket. The files included with an Exclusive item, or substantially the same implementation adapted, repackaged, or renamed, must not be offered for sale or distribution outside Wrapmarket.

A separate implementation of the same underlying design for a different format, platform, or technology may be sold outside Wrapmarket. For example, a creator may sell an HTML implementation of a design exclusively on Wrapmarket while selling a Figma implementation of the same design elsewhere.

Exporting or converting substantially the same source asset into another file format does not by itself create a separate implementation. A separate implementation must involve meaningful work specific to the different format, platform, or technology rather than only conversion, repackaging, or minor adaptation.

  • Changing only the name, branding, sample content, minor design details, or other superficial elements does not create a separate implementation.
  • Wrapmarket reserves the right to investigate exclusivity claims and decide eligibility.
  • When submitting an item, if the same implementation is already available elsewhere, mark it Non-Exclusive or remove the conflicting external listings before submitting it as Exclusive.
  • You are responsible for keeping the exclusivity setting accurate after publication.

Core acceptance standards

This section describes the fundamental standards used to determine whether an item is suitable for Wrapmarket. It covers topics such as customer readiness, originality, content suitability, and design quality.

An item may be functional and visually polished but still not meet the quality standard if it is too minimal, generic, insufficiently refined, or does not provide the scope and practical value customers reasonably expect from a current item in its category.

General quality standard

An item must be complete, tested, and ready for use by a paying customer when it is submitted. Do not submit an unfinished concept, early prototype, demonstration project, or partially prepared package with the expectation that the review process will identify everything that remains to be completed.

Wrapmarket does not require a particular visual style, technical architecture, or creative direction. The finished item should demonstrate coherent and deliberate decisions appropriate to its represented purpose.

Customer readiness and correct operation are necessary but do not establish quality by themselves. The item must also provide sufficient scope, depth, refinement, and practical value for its purpose and category. Current customer expectations for comparable items may be considered.

Originality and creator contribution

Using a framework, starter, example project, component library, or third-party material does not by itself create an original item. A substantial portion of the item's customer value must come from the creator's own design or implementation decisions.

The item must contain meaningful original work and must not copy, imitate, or rework another creator's item. A lightly modified example project, superficially customized starter, or collection of third-party materials does not constitute meaningful creator contribution, even when the source materials may legally be used.

Third-party components, libraries, frameworks, and assets may support the item, but they must not replace the creator's contribution or constitute the item's primary value.

This does not prevent an authorized separate implementation of a shared underlying design when it represents meaningful implementation work and follows the requirements under Item groups.

Differentiation from your other items

Each item must be meaningfully differentiated from the creator's other published items and submissions. Creators may reuse a common technical foundation, component system, or development workflow, but the finished item must provide a materially distinct design, purpose, content structure, or set of features.

Changes limited primarily to branding, colors, sample content, minor layout adjustments, or other superficial details do not create a meaningfully distinct item.

Rights and permissions

You must have the rights necessary to sell and distribute the item and all materials included or displayed as part of its submission. This includes materials used in the download package, listing, thumbnail, screenshots, live preview, documentation, and sample content.

These requirements apply to code, designs, layouts, images, illustrations, icons, fonts, videos, written content, plugins, libraries, components, and other assets.

Do not submit content that infringes copyrights, trademarks, privacy rights, licenses, or other rights. The presence of material on a website, repository, or design platform does not establish that it may be used in a commercial item.

Third-party components and assets

Third-party components and assets may be used only when their licenses or other terms permit the way they are included, displayed, and distributed.

Identify in the item documentation any third-party components or assets that customers must obtain separately, license, attribute, or otherwise account for when using the item. Do not imply that customers receive rights that neither you nor Wrapmarket are authorized to grant.

If a preview uses third-party content that cannot be distributed, substitute appropriate placeholder content in the package and clearly disclose that the preview content is not included.

Content suitability

The item and all submission materials must be suitable for a general professional marketplace. Do not include unlawful content, sexually explicit content, hate speech, harassment, threats, graphic violence, discriminatory or dehumanizing content, or material that promotes harmful or illegal activity.

Example and placeholder content must follow the same standard. Content is not exempt merely because it appears only in a preview, screenshot, sample database, or part of the item that is not shown on the main listing.

AI-generated and AI-assisted content

AI-generated and AI-assisted work is evaluated under the same standards for originality, depth, usability, technical quality, refinement, and customer readiness as other work.

You must select the disclosure that best describes how the core item was created:

  • No AI used
    Generative AI was not used to create or substantially refine the item.
  • AI-assisted
    AI helped create or refine portions of the item, but the item remains primarily human-made.
  • Primarily AI-generated
    AI created a substantial portion of the item's core design, layouts, graphics, text, code, or other included assets.

Minor corrections such as spellcheck do not ordinarily require the AI-assisted disclosure. AI-assisted and primarily AI-generated work must be meaningfully reviewed, refined, tested, and prepared for customer use. Unedited or minimally edited generated output may not meet the quality standard.

AI-assisted and primarily AI-generated work should demonstrate clear creative direction and deliberate design and development decisions beyond the default patterns, conventions, or characteristic output of the tools used to create it.

  • An item may not meet the quality standard when it relies heavily on generic or repeated generated patterns, is substantially interchangeable with similar generated work, or presents surface polish without sufficient depth, usability, technical quality, or attention to detail.
  • No particular tool, visual convention, or use of AI is disqualifying by itself.
  • The finished item is evaluated as a whole.
  • You remain responsible for confirming that AI-generated content may be used and distributed as part of the item.

Design and visual quality

The visual design should be deliberate, coherent, and professionally finished. Typography, spacing, alignment, sizing, color, imagery, and component styling should be applied consistently and support a clear visual hierarchy.

Interfaces should be reasonably clear and usable. Layouts, navigation, labels, controls, and content hierarchy should make the item's structure and intended use understandable.

Items represented as responsive should maintain their visual quality and must remain usable and preserve their content integrity across the screen sizes shown or claimed in the listing and live preview.

Placeholder and example content may be used where appropriate, but it should support a coherent presentation and should not leave the item appearing unfinished.

Functional completeness and customer experience

The item must be complete and usable for its advertised purpose, not only in the portions emphasized in its listing or preview. Delivered files must open and be usable as intended. Missing resources, broken links, unresolved errors, incomplete sections, or other defects must not materially interfere with normal use.

Where applicable, features, controls, interactions, and workflows should behave consistently and provide appropriate feedback. The item should account for the important states and conditions customers are reasonably likely to encounter when using or customizing it.

Pages, layouts, components, and other included content should serve a clear purpose and provide meaningful value. Do not inflate the apparent scope of an item with superficial duplicates or represent it as providing functionality, systems, or services that are not included.


Item listing and presentation

This section explains how to categorize, name, group, describe, and present an item accurately and professionally. It covers listing claims, writing and content quality, Markdown formatting, search information, thumbnails, screenshots, live previews, and other listing requirements.

Listing accuracy

The item listing, live preview, screenshots, thumbnail, documentation, and download package must always accurately describe and represent the same item.

All significant functionality, pages, components, layouts, file formats, technical implementations, and assets advertised as included must be present in the download package.

Images, photographs, videos, mockups, fonts, icons, and other demonstration materials shown in the preview but not included in the package should be identified in the item description as preview or example content where their absence may not otherwise be clear.

Placeholder reviews or testimonials may appear when they are reasonably necessary to demonstrate a template or component, but they must be clearly fictional and must not imply that the item has received actual reviews, endorsements, or customer results.

Writing and content quality

Text throughout the item and submission should be clear, readable, and professionally presented. Review the listing, preview, screenshots, interface text, documentation, sample content, source comments, and included files for spelling, grammar, punctuation, broken characters, incomplete sentences, and inconsistent terminology.

Use the official, current name, spelling, capitalization, and punctuation for frameworks, libraries, platforms, languages, file formats, and other technologies. Apply these names consistently throughout the item and listing rather than inventing variations or using outdated branding.

Repeated writing errors, awkward or nonsensical generated text, copied instructions that do not apply, and unfinished placeholder wording may cause an otherwise usable item to appear incomplete or poorly prepared. Placeholder content may be used when appropriate, but customer instructions and claims about the item must be complete and accurate.

Categories and restrictions

An item may be published only when Wrapmarket has an appropriate category for it. Select the category that accurately describes the item being delivered.

Do not place an unsupported item into a loosely related category merely to make it eligible for submission.

Categories that are marked as coming soon may accept submissions before their customer-facing launch. Accepted items remain unpublished until the category is ready to open. Acceptance does not guarantee a launch date. Wrapmarket may require an accepted item to be updated or reviewed again if category requirements, supported formats, or customer expectations change before launch.

Categories, search phrases, topics, and compatibility

Categories, search phrases, topics, and compatibility selections describe different aspects of an item:

  • Category
    Identifies the primary kind of product being delivered. Each item has one category.
  • Search phrases and topics
    Creators provide search phrases that accurately describe the item's subject, purpose, audience, style, or use case. Wrapmarket uses those phrases to derive topics for browsing and discovery. Creators do not select topics directly, and topics do not replace the category.
  • Compatibility selections
    Identify supported platforms, technologies, applications, or formats when the category offers those choices.

Select the category and all applicable compatibility options accurately. Provide search phrases that truthfully describe the item. Do not use search phrases or compatibility selections to imply that an item belongs to another category, supports something it does not, or includes a separate product that is not delivered.

Categories:

  • Website Templates
    Coded templates for websites and web interfaces.
  • WordPress Themes
    Installable WordPress themes. Standalone plugins and items whose primary product is a plugin are not permitted.
  • Framer Templates
    Website templates created for Framer and delivered using a valid Framer remix link.
  • Webflow Templates
    Complete website templates implemented in Webflow and delivered through a valid Webflow template fulfillment link. Static design source files and templates implemented for a different platform do not belong here.
  • Shopify Themes
    Installable themes for Shopify online stores. Standalone apps, app extensions, section packs, and items whose primary product is not a complete Shopify theme do not belong here.
  • UI Kits
    Editable design source systems and interface layout packs used to design digital products. This includes reusable components and design systems, wireframes, complete website page sets, landing page layouts, dashboards, web apps, and mobile app screens and flows. Coded templates, installable themes, print layouts, presentation templates, and standalone icon, illustration, or font libraries do not belong here.
  • Mockups
    Editable presentation assets whose primary purpose is to place a customer's artwork, interface, packaging, or branding into a realistic or intentionally stylized scene. The advertised replaceable areas and editing workflow must be included. Static photographs or illustrations, finished branding assets, complete interface layouts, product photography, and files that merely use a mockup to advertise another item do not belong here.
  • 3D Assets
    Editable three-dimensional source assets intended for use in 3D software, including models, scenes, materials, textures, rigs, and similar production resources. The package must include the underlying usable 3D files. Packs containing only rendered images, including static images marketed as 3D icons, belong in Icon Sets or Illustrations rather than this category.
  • Logos & Branding
    Editable logo templates and coordinated identity assets intended to help create or present a visual brand, including logo systems and brand-guideline templates. Generic illustrations, icon libraries, and mockups belong in their respective categories. Standalone font products are not currently supported.
  • Presentations
    Editable slide-deck systems created for presentation software. Documents, brochures, social-media layouts, and static presentation mockups do not belong here.
  • Icon Sets
    Cohesive collections of reusable interface, product, or communication icons. A single logo, a general illustration pack, and a UI kit whose icons are only supporting components do not belong here.
  • Illustrations
    Cohesive collections of original editable illustrations intended for reuse in digital or print compositions. Icon sets, stock photography, mockup scenes, and interface kits do not belong here.

An item must not combine independently complete products whose primary purposes place them in different categories. For example, a Website Template and a WordPress Theme must be submitted as separate items.

Subordinate materials that support the primary item are permitted when they are reasonably useful to its advertised purpose. A UI Kit may contain supporting icons, a branding product may use included application mockups, and a 3D Asset may include rendered preview images. Supporting material must not be represented as an independently complete additional product or used to avoid submitting that product in its appropriate category.

Supplementary editable design sources may be included with an implementation even when those files could qualify for UI Kits on their own. For example, a Website Template may include its related Figma design files. A separate item within the same item group is usually preferred when the design version is complete enough to be sold independently, but separate publication is not required.

Use category terms accurately throughout the listing, preview, screenshots, documentation, search phrases, and package materials. Do not use template and theme interchangeably. A theme is a specific type of item, not a general synonym for a template.

For example, do not describe a Website Template as a Website Theme or otherwise use theme in a way that could imply compatibility that the item does not provide. These terms may still be used when they accurately name a specific technical feature or file type.

Choosing an item name

Every item must have a unique name that is sufficiently distinct from existing items to avoid customer confusion.

Use the following format:

Name - Descriptive Keywords

The item group name must appear before the hyphen. Use the descriptive keywords after the hyphen to accurately identify the item's purpose, category, or important features.

  • Keep the descriptive portion concise. Do not stuff the item name with long, repetitive, unrelated, or awkward strings of keywords. Use search phrases for additional accurate keywords and synonyms.
  • Before preparing the listing and branded materials, use marketplace search to confirm that the intended item group name is available. Search for spelling variations that could cause confusion with an existing name.
  • Use the item group name consistently wherever the item itself is identified or branded, including the listing, thumbnail, screenshots, live preview, documentation, package files, and source metadata.
  • Sample content within an item may use a fictional business, product, or organization name and logo. This sample branding does not need to match the item group name, but it must be clear that it belongs to the example design and is not the name or branding of the item itself.
  • If an item name must be changed, update the item logo, listing, thumbnail, screenshots, preview, documentation, package files, source comments, and other references where applicable.

Item groups

The unique portion of an item name acts as its item group name. Item groups connect separate implementations of the same underlying design so Wrapmarket can show the implementation most relevant to a customer's category, search, topic, or compatibility filters. Customers viewing one item may also discover the related implementations in its group.

Substantially different implementations of a design should usually be sold as separate items.

Items within a group must represent the same underlying design and use the same item group name. They must be described accurately as distinct implementations rather than as interchangeable files.

Different creators may use the same item group name when they have agreed to sell separate implementations of the same underlying design from their respective accounts. Otherwise, the item group name must not be reused.

Item splitting

Item splitting means separating a new or existing item that contains multiple implementations into distinct item listings. Wrapmarket may request an item to be split when separate packages, descriptions, documentation, previews, or compatibility selections would be clearer for customers to evaluate, purchase, use, or maintain.

Before splitting an existing item, contact Wrapmarket Support to coordinate and plan the resulting listings.

How a product is packaged or sold outside Wrapmarket does not determine how it should be organized on Wrapmarket.

Each split item must be complete and usable on its own. It must have a download package, description, compatibility selections when offered for its category, documentation, and preview or screenshots that accurately represent only that item. The listing must clearly identify what is included and must not imply that the customer receives other items created by the split.

When split items are separate implementations of the same design, they must use the same item group name. The descriptive portion of each item name must distinguish its framework, platform, format, or other implementation. If a combined item contains substantially different designs or products, each must use a different item group name.

  • Do not create separate listings for implementations that differ only through branding, colors, sample content, minor layout changes, or other superficial variations.
  • Do not duplicate substantially the same implementation across multiple listings merely to create additional items.

Description

The description must provide customers with enough information to understand what the item is, what it includes, how it may be used, and what distinguishes it from other items of the same type.

See also: Representing Wrapmarket policies, Advertising and promotional material

A brief introduction or general marketing statement is not sufficient by itself. The description should identify the included pages, screens, layouts, components, files, or other substantial content, describe important features, and point out the qualities that meaningfully distinguish the item from others in its category.

Descriptions must be formatted using Markdown and structured for readability. Unformatted plain text and raw HTML are not permitted. See the supported Markdown syntax reference below.

The first line should introduce or describe the item rather than repeat the item name. Emojis should be used sparingly and only when they improve clarity or presentation. Avoid decorative or repeated emoji use that makes the listing difficult to scan or causes it to appear unprofessional.

Where applicable, include:

  • A clear overview of the item's purpose and target audience.
  • A list of included pages, screens, layouts, components, or files.
  • A list of important features and technical details.
  • Supported frameworks, formats, platforms, browsers, or software.
  • Required third-party tools, services, plugins, libraries, or accounts.
  • Important limitations or exclusions.
  • Information that helps distinguish the item from similar alternatives.

Supported Markdown syntax

Use the Markdown preview while editing to confirm that the description renders as intended.

The following syntax is supported:

Element Syntax
Headings ## Example H2 or ### Example H3 or #### Example H4
Horizontal rule ---
Bold text **Bold text**
Italic text *Italic text*
Strikethrough ~~Strikethrough text~~
Bulleted list - List item or * List item
Numbered list 1. List item
Link [Link text](https://example.com)
Blockquote > Quoted text
Inline code `code`
Code block

Place three backticks on a separate line before and after the code.

```
if (true) {
    console.log('Hello Wrapmarket');
}
```
Table
| Heading | Heading | Heading |
| --- | --- | --- |
| Column | Column | Column |

Separate paragraphs with a blank line. Explicit URLs beginning with https:// or http:// are linked automatically. Images, raw HTML, task lists, footnotes, and other Markdown extensions not listed above are not supported. Upload item imagery through the thumbnail and screenshots instead.

Search phrases

Provide relevant phrases that customers are likely to use when searching. The search phrases may describe the item's purpose, design, audience, features, use cases, industries, styles, and other meaningful characteristics.

You may provide up to 40 phrases to help customers find your item. Separate phrases with commas and use only letters, digits, spaces, and periods within each phrase.

Focus on describing the item accurately rather than trying to reproduce or reverse-engineer the marketplace's navigation. Include accurate keywords and useful synonyms.

Restrictions

  • Do not include unrelated technologies, industries, use cases, styles, or features merely to attract additional search traffic. A customer should consider the item relevant when it appears for each submitted phrase.
  • Do not use the item group name, your creator name, names of competing or similar items, other creators, external marketplaces, or storefronts as search phrases.
  • Do not submit duplicate or near-duplicate search phrases. Do not enter separate phrases for singular and plural forms, minor spelling or punctuation variations, or reordered versions of the same words. Use the available phrases for distinct terms and concepts instead.

Feature bullet points

Provide three concise bullet points that communicate specific features, use cases, included content, or technical details. Each bullet point may contain up to 50 characters.

The feature bullet points appear on item cards and should give customers three specific reasons to examine the item more closely. Keep them distinct and factual. Avoid repeating the item name, restating the category, making vague promotional claims, or using three variations of the same feature.

The feature bullet points are not used for search ranking. Do not fill them with keywords or search phrases that provide no useful information to customers.

Thumbnail

The thumbnail is the primary image representing the item and is often the first thing a customer sees. It must clearly show the item's design or purpose and should remain legible at smaller display sizes.

Technical requirements:

Specification Requirement
Format 24-bit PNG
Dimensions 1920 × 1080
Maximum file size 5 MB
Transparency Not permitted
Rounded outer corners Not permitted

The thumbnail must be high quality. It must not contain blurry or upscaled screenshots, illegible text, visible compression artifacts, distorted imagery, or misaligned elements. These requirements also apply to logos, screenshots, icons, and other elements used within the image.

A custom thumbnail should use a clear visual hierarchy, balanced spacing, cohesive typography and color, and a composition that represents the item professionally. Meeting the technical dimensions does not make a poorly composed, cluttered, or visually inconsistent image acceptable.

A well-chosen screenshot may be used when it represents the item more accurately than a promotional composition.

Screenshots

The screenshots should help customers evaluate the item's visual design, included content, important features, and range of layouts or components. Marketing images are permitted provided they accurately represent the item.

Technical requirements:

Specification Requirement
Format 24-bit PNG
Minimum dimensions 1920 × 1080
Maximum file size 15 MB per image
Maximum number 100 images
Transparency Not permitted
Rounded outer corners Not permitted

Upload high-resolution images that show the item clearly. Do not use blurry, heavily compressed, needlessly repetitive, or misleading screenshots. None of the uploaded screenshot images may duplicate the thumbnail image.

Arrange screenshots in a useful order. The first images should communicate the strongest and most representative parts of the item, followed by additional pages, features, layouts, responsive views, or technical variations.

Creative asset categories

For UI Kits, Mockups, 3D Assets, Logos & Branding, Presentations, Icon Sets, and Illustrations, screenshots are the primary way customers evaluate the delivered content. Show the actual included work clearly rather than relying only on promotional compositions, decorative mockups, or sample applications.

  • UI Kits:
    Show a representative range of the included screens, flows, components, layouts, variants, and states. A small number of promotional images may not be sufficient for a large kit. Every screen does not need to be shown, but the screenshots must fairly communicate the kit's scope, visual quality, consistency, and included content.
  • Mockups:
    Show the included base scenes, advertised replaceable areas, and representative finished results.
  • 3D Assets:
    Show the asset from useful angles and, where applicable, include evidence of its wireframe or topology, UV preparation, materials, rig, or animation.
  • Logos & Branding:
    Show the actual marks, lockups, variants, and representative brand-guideline pages. Mockup applications may support the presentation but must not replace a clear view of the identity assets.
  • Presentations:
    Show readable full slides and a representative range of layouts, masters, content types, and visual styles included in the deck.
  • Icon Sets:
    Show an overview that fairly represents the complete set as well as close views that make the icons' design and consistency legible.
  • Illustrations:
    Show the actual range of included subjects, scenes, styles, and meaningful variants.

When advertising the number of included assets or designs, count distinct original works accurately. Changes limited to color, size, resolution, export format, camera angle, or adaptation of the same design to another slide size or canvas are variants, not separate original assets.

Live preview

See also: Representing Wrapmarket policies, Advertising and promotional material

For items within a category where a preview is required, the preview must allow customers to evaluate the design and functionality advertised on the listing. Keep the preview available while the item is listed. If the domain expires or the preview URL changes, update the listing promptly.

The preview must be accessible through the submitted URL, served over HTTPS with a valid SSL certificate, and load and respond within a reasonable amount of time. It must not contain broken pages, missing assets, unresolved errors, or functionality that materially differs from the download package.

For Shopify Themes, provide a persistent customer-accessible demo store and keep any access instructions current while the item is listed. A time-limited Shopify visitor-preview link is not an acceptable live preview.

The preview should include a clear and working link back to the corresponding Wrapmarket item listing so customers can return to the listing after evaluating the item.


Download package and documentation

This section describes what customers should receive after licensing an item and how those materials should be organized. It covers package contents, source and production files, documentation, and delivery instructions.

Download package

The download package is delivered to customers. Do not include reviewer notes, submission checklists, draft promotional materials, or files used only to prepare the submission.

The download package must provide the complete item and everything described as included on the listing.

Except for a category-specific link-delivery method described below, the package must contain the actual item files. A link to download, duplicate, or clone files from another website or cloud service is not a substitute for including them in the ZIP archive.

Technical requirements:

Specification Requirement
Format ZIP compressed archive (.zip)
Maximum file size 2 GB
Encryption / password protection Not permitted

Organize the package so customers can identify the main item files, documentation, source files, production files, and optional resources. Remove caches, backups, private project files, and generated files, dependency directories, or development artifacts that are not required for customer use or production operation.

Include the editable source files and usable production files reasonably necessary for the advertised use and customization of the item. Where a build process is required, provide complete instructions and confirm that a clean build reproduces a usable version of the item.

Framer Templates category

The package must contain a clearly named text, PDF, or HTML file that includes a valid Framer remix link and brief instructions for copying the project into the customer's workspace. Test the link before submission and keep it available while the item is listed. A published site, other view-only link, or link that requires the creator to approve each customer's access is not an acceptable product deliverable.

Webflow Templates category

The package must contain a clearly named text, PDF, or HTML file that includes a valid Webflow template fulfillment link and brief instructions for installing the template in the customer's Workspace. Test the complete template installation process before submission and keep the link available while the item is listed. A public preview or a link that requires the creator to approve each customer's access is not an acceptable product deliverable.

Shopify Themes category

The download package must include an installable Shopify theme ZIP, separate from the documentation and any optional source or development files. Follow Shopify's theme upload workflow and theme architecture. Test the supplied theme ZIP by uploading it to a Shopify development store before submission. It must install and function using the documented process.

Creative asset categories

Creative asset packages must include all actual editable working files, resources, and promised exports reasonably necessary to use the item as advertised. Do not substitute a link that downloads, duplicates, clones, or otherwise provides the item from another website or cloud service. An external link may be included only as an optional convenience, and the files in the ZIP archive must remain complete and usable without it.

  • UI Kits:
    Include every advertised screen, page, flow, component, design system, and reusable element in the editable working files.
  • Mockups:
    Include each advertised scene and replaceable area with the working layers, objects, effects, and linked or embedded resources needed to perform the documented replacement process.
  • 3D Assets:
    Include usable geometry and all advertised materials, textures, maps, rigs, animations, scene files, and other production resources. Rendered previews do not replace the underlying 3D files.
  • Logos & Branding:
    Include the promised editable or vector sources, logo lockups and variants, brand-guideline files, and other identity assets represented on the listing.
  • Icon Sets:
    Include every advertised icon, with meaningful filenames, consistent grids or view boxes, and the promised editable source and export formats.
  • Illustrations:
    Include every advertised illustration and meaningful variant in the represented editable source or production formats.

Presentations category

Provide a complete editable deliverable for every advertised presentation format. For file-based formats, include the editable product file in the ZIP archive. Each format must contain the masters, layouts, charts, media, editable elements, and animations, and must be tested independently rather than assumed to work because another version does.

Google Slides compatibility

The download package must contain a clearly named text, PDF, or HTML file with a working Google Slides make-a-copy link to the native presentation and brief instructions for copying it. The link must let the customer create an independent editable copy in their own Google Drive account without requiring the creator to approve access.

Test the complete copy process using a separate Google account and keep the link available while the item is listed. A published or view-only preview, a standard Drive sharing link that does not open the make-a-copy workflow, or a .gslides pointer is not an acceptable product deliverable. A .pptx file may be included as an optional backup, but it does not establish Google Slides compatibility by itself.

Do not include stock media supplied through Google Workspace in a template offered for sale.

Documentation

See also: Representing Wrapmarket policies, Advertising and promotional material

Every item must include documentation or clearly identified help files in the download package that give customers the information reasonably necessary to begin using and modifying the item.

Documentation may be provided as HTML, PDF, Markdown, plain text, or another format customers can open easily. A README or instructions file is acceptable only when its content satisfies the documentation requirements. Providing a minimally populated file does not satisfy the requirement merely because it is labeled as documentation.

Because documentation is part of the customer experience, it must be accurate and up to date. It should be readable, organized, and professionally presented. It does not need an elaborate or custom design, but its organization and presentation should make the instructions clear and easy to follow.

Where applicable, use clear typography, spacing, navigation, screenshots, terminology, and visual structure.

Update documentation that contains obsolete instructions, outdated screenshots or branding, broken layouts or links, references to unsupported versions, or presentation that no longer represents the current item.

Where applicable, documentation should:

  • Explain the package and source-file structure.
  • List required software, dependencies, accounts, and build tools.
  • Describe setup and installation.
  • Provide the commands or steps needed to install dependencies and create a production build.
  • Guide customers through basic configuration and customization.
  • Provide the information and disclosures described under Third-party components and assets.

For creative asset and presentation items, documentation must identify the supplied working and export formats and explain the normal editing workflow. Where applicable, it must also disclose:

  • Mockups:
    Document the replacement process, file dimensions, resolution, color mode, and any required features or plugins.
  • 3D Assets:
    Document the file formats, software and tested versions, renderer or plugins, scale and units, topology, UV preparation, texture and map types and resolutions, rigs, and animations.
  • Logos & Branding:
    Identify required fonts, whether they are included, and any substitutions or separately obtained resources needed to edit the assets.
  • Presentations:
    Identify required software, fonts, media, and any material differences or limitations among the delivered formats.
  • Icon Sets and Illustrations:
    Identify the included source and export formats and any relevant dimensions, resolutions, color modes, or editing requirements.

Documentation does not need to teach customers the underlying programming language, framework, design application, hosting environment, or other technology. It should explain how those technologies are used by the item.


Technical and development standards

This section describes the technical and source-file preparation expected for applicable items. It covers code and source quality, dependencies, compatibility, required services, security, privacy, installation, data safety, and accessibility.

Technical quality

Core dependencies should use current, stable, and supported versions. Dependencies must be updated when their age, support status, or known vulnerabilities materially affect usability or security.

Production readiness

Where an item is installed, built, or run, it must work from the download package using the documented process. Where a production build process exists, use it and include production-ready files. Do not rely on development-only runtimes, preview servers, browser-based compilers, or other tooling identified as unsuitable for production.

Code, markup, stylesheets, configuration files, and structured data must use valid syntax. Resolve avoidable warnings, debugging output, unresolved placeholders, and errors that occur during normal intended use before submission.

Design files, 3D scenes, presentation decks, and other creative source files must open cleanly in the represented software, remain editable as advertised, and include the resources necessary for normal use. Resolve missing links, fonts, images, textures, media, plugins, substitutions, and other dependencies, or clearly disclose and document any resource the customer must obtain separately.

Source quality and maintainability

Code, design documents, 3D scenes, presentation decks, and other source files should be organized, understandable, maintainable, and suitable for customer use. Customers should be able to identify the package structure and work with the source files using the documented process.

  • Formatting, indentation, naming, file organization, and comments should be reasonably consistent and follow established practices for the language, framework, or platform.
  • Layers, objects, pages, components, styles, masters, materials, rigs, and similar editable structures should be named and organized appropriately for customer use.
  • Avoid unnecessary duplication, dead code, inaccurate comments, and temporary development workarounds.
  • Follow reasonable practices for maintainability, performance, error handling, and dependency management.

Compatibility and requirements

Compatibility selections, when offered for the category, and disclosed requirements must give customers an accurate understanding of the technologies they can work with and anything they need to use or customize the item.

Each compatibility selection is a customer-facing claim. Select only options that materially describe the delivered item and have a reasonable basis in testing. An item does not need to support technologies, platforms, formats, or tools that are not represented as compatible.

Compatibility selections

Compatibility selections must describe the customer-facing source or working formats provided in the package, not every technology that appears somewhere in the implementation.

Some categories do not offer compatibility selections. When no selections are offered for the chosen category, none are required. The item description and documentation must still identify its actual working formats, required software, and other material requirements.

Do not select a technology solely because it:

  • Is an incidental dependency.
  • Appears only in compiled or generated output.
  • Supports one auxiliary feature.
  • Is used internally by a build tool.
  • Is used only to operate the live preview.

For example, a PHP contact-form script does not by itself make an otherwise front-end template compatible with PHP.

Select HTML, CSS, or JavaScript only when the package includes those as source formats customers are expected to work with directly. Do not select HTML merely because a framework renders HTML or because the package contains generated output. A customer looking specifically for an HTML template should not be misled by the selection.

Versions and tested environments

Provide version information where requested. Use the narrowest version or range that accurately represents compatibility. Ranges such as 5.x or 5.3.x may be used when there is a reasonable basis for expecting the item to work throughout the represented range.

For applicable web items, select only browsers in which the item has been tested and its advertised functionality works as intended. Customers should be able to rely on each selected browser as a supported environment.

Customer requirements

Clearly disclose any software, service, account, plugin, font, API, hosting environment, build tool, or third-party resource required to install, open, edit, build, host, or use the item. Distinguish required resources from optional ones and identify the part of the item or workflow to which each requirement applies.

Requirements that materially affect whether a customer can use the item must be disclosed in the item description before purchase. This includes any additional purchase, paid subscription, usage-based charge, account registration, API key, quota, regional limitation, or service plan. Material limitations of a free plan must also be disclosed when they affect advertised functionality. Detailed setup instructions may be provided in the documentation.

Security, privacy, and external connections

Items must be safe to use. They must not contain harmful behavior, real private or sensitive data, active credentials, or other secrets not intended for distribution.

Material external connections and any collection or transmission of data must be clearly disclosed.

Customers must be able to understand when an item connects to an external service, what the connection does, and whether it collects or transmits data.

Security and sensitive data

Items must not contain malicious code, backdoors, cryptocurrency miners, deceptive behavior, or code intended to gain unauthorized access, conceal harmful functionality, or interfere with a customer's systems or data.

Do not include:

  • Real customer or personal information, private communications, production database data, or other private content.
  • Active credentials, passwords, API keys, access tokens, or reusable default passwords.
  • Private URLs or other secrets not intended for customer distribution.

Example data must be fictional and safe to distribute. Placeholder credentials must be nonfunctional and clearly identified as values the customer must replace.

External connections and data collection

External connections must serve a legitimate item-related purpose. Material connections must be accurately disclosed and documented. This includes analytics, telemetry, tracking, remote APIs, externally hosted assets, remote configuration, update services, license checks, and connections to creator-controlled servers.

Documentation must identify the purpose of each material connection, whether it is required or optional, and the types of data it sends or receives. Explain how optional connections can be configured or disabled where applicable.

An item must not secretly collect or transmit customer, visitor, project, or usage data. Any collection or transmission of data must be appropriate for the advertised functionality, clearly disclosed, and lawfully implemented. Do not collect more data than reasonably necessary for the stated purpose.

Remote code and services

Do not load executable code or introduce material functionality from a remote source without clear disclosure. Remote code, configuration, or services must not be used to conceal functionality or change the item in a way that a customer would not reasonably expect.

If important functionality depends on an external or creator-controlled service, disclose it as a requirement and explain the dependency, its limitations, and what happens if the service becomes unavailable. Connection failures must not expose or corrupt customer data or leave the item in an unsafe state.

Installation, updates, and data safety

Installation, import, migration, update, and removal processes should be safe and appropriate for the intended customer. They must not unexpectedly overwrite content, reset configuration, remove files, modify unrelated data, or perform another destructive action without clear notice and confirmation.

Document backup requirements, permissions, database changes, irreversible steps, and other material risks before the customer performs the action. Updates should preserve customer content and configuration where reasonably expected, or clearly explain any breaking change and the steps necessary to complete the update.

Sample content, import files, and setup tools must work as documented and must not depend on private files, temporary URLs, or creator-controlled resources that are not disclosed and intended to remain available.

Accessibility and inclusive use

Items should follow reasonable accessibility practices appropriate to their format and intended use. Where applicable, this includes semantic structure, keyboard-accessible controls, visible focus states, associated form labels, understandable validation messages, alternative text, sufficient contrast, and text that remains legible when resized.

Wrapmarket review is not a complete accessibility audit. Creators remain responsible for testing the item and for accurately describing any accessibility support or limitations.


Item releases

This section explains how to prepare and release updates after an item is published. It covers complete replacement packages, versions and changelogs, coordination of listing and preview changes, and the boundary between updating and replacing an item.

While an item remains available, creators are responsible for monitoring its core dependencies and releasing updates when reasonably necessary for security, compatibility, or continued customer use.

Preparing an item release

Every release must provide a complete, usable replacement package rather than only the files changed since the previous version. Include the current source files, production files, documentation, and other materials customers need to use the updated item.

Test the final package from a clean copy before releasing it. Where applicable, confirm that installation, dependency installation, builds, imports, migrations, updates, major features, and included links work without relying on files or configuration left over from development.

Review core dependencies as part of release preparation. Use current stable dependency versions when reasonably possible and address obsolete, unsupported, incompatible, or insecure dependencies before they create avoidable problems for customers.

Item releases do not go through review before becoming available. They become available immediately and customers who previously licensed the item may be notified. Do not release an incomplete, untested, or incorrectly packaged update with the expectation of replacing it later.

Versions and changelogs

Use a version number in Major.Minor.Patch format, such as 1.0.0. The version must increase with every release.

Each release must include a clear changelog describing relevant new features, bug fixes, compatibility changes, improvements, removals, and other customer-facing changes. Write for customers rather than using only internal commit messages or vague entries such as "minor changes."

Identify breaking changes, removed features, changed requirements, and migration or upgrade steps prominently enough for existing customers to understand how the release affects them.

Coordinating listing and preview changes

Immediately before releasing an update, revise the item listing and, where applicable, the preview so the changes are ready for existing and prospective customers to view when the release becomes available. Coordinate these changes closely with the release to avoid advertising unavailable features or leaving customers with outdated information.

Review the complete listing after every material update. Update the description, compatibility selections, feature bullet points, search phrases, and other affected information so each accurately represents the released package. Replace the thumbnail, screenshots, or marketing images that no longer represent the current item.

Where applicable, confirm that the updated preview works and links back to the Wrapmarket item listing.

Item identity and replacement

An update must remain a continuation of the item customers licensed. It may modernize the design, rebuild or refactor the implementation, adopt current dependencies, and add, remove, or improve features when the result is still reasonably understood as a new version of the same item.

Describe substantial redesigns, breaking changes, and changes in technical direction clearly. Wrapmarket may require an update to be submitted as a new item when it does not preserve reasonable continuity with the existing item.

Restrictions

Creators cannot change an item's category through a release. A proposed update that belongs in another category must be submitted as a new item. Do not use an update to add a product or implementation that belongs in another category. Supplementary editable design sources described in the category guidance may continue to be included.

Wrapmarket may administratively reclassify an item after publication to correct an inaccurate assignment or to maintain the marketplace category structure. Reclassification does not authorize a creator to replace the item with a different product.

Do not replace an established listing with an unrelated item or repurpose its listing history, customer base, visibility, or item group name for a different product. A change should normally be submitted as a new item when it has a different identity or primary purpose, represents a separate implementation that would be clearer as its own item, or would cause the existing listing and release history to describe a materially different product.

Do not release an update that adds an unrelated item to an existing listing, or makes a previously rejected item available through a published item.

An item that was previously rejected must not be added in whole or in part to an existing item as an update, alternate version, bonus, optional package, or other included material. Any substantially reworked version intended for publication must follow the appropriate item submission process.


Compliance and corrective action

Publication is based on the item and materials reviewed at that time. While an item remains available, you are responsible for ensuring that the item and its customer-facing materials comply with the applicable Quality Guidelines and policies, including after subsequent releases.

Items may be required to meet updated requirements while they remain available.

When an issue is identified after publication, Wrapmarket may ask the creator to provide a correction or updated release. The appropriate response may depend on the issue's nature, severity, customer impact, available remedies, and whether the creator can reasonably correct it.

Some circumstances may require quicker action. If the creator is unavailable, a correction is not practical, or the issue materially affects customers, rights, security, accuracy, or marketplace policy, Wrapmarket may restrict sales or downloads, roll back a release, remove the item, or take another action appropriate to the circumstances.