Roblox In-Game Image Publishing (October 19, 2026): PromptCreatePlatformContentAsync, Rules, and Makeup Differences

Wed Oct 21, 2026 3:53 am

Quick Summary

On October 19, 2026, Roblox released in-game EditableImage publishing. Players can now upload an image they made inside a game straight to their own inventory.
The old prompt method was renamed to AssetService:PromptCreatePlatformContentAsync and now takes an Object instead of an Instance, so an EditableImage can be passed directly.
Published images land in the player's inventory as Image assets. Players own them outright, including the right to export them off platform.
This is the general purpose sibling to the makeup creation feature that launched on October 15. That one is limited to five makeup item types and requires Avatar Creation Tokens.
Only EditableImages are supported today. Audio and mesh publishing are not in this release, and Roblox has not committed to a date for either.

What Roblox announced on October 19

Roblox staff member Bitwise posted the update to the Developer Forum under the title "In-Game Editable Image Publishing." It covers two changes at once, and the second one is the substantive part.

First, the rename. The method previously known as the prompt publish asset method is now AssetService:PromptCreatePlatformContentAsync(player, object, assetType). The signature change matters more than the new name, because it accepts an Object rather than an Instance. Roblox framed that as setting "a cleaner standard for how in-game creation and publishing prompts will function as the platform expands," which is their way of saying the method is being built to accept asset types that are not Instances.

Second, image publishing is live. Uploading an EditableImage through that method is fully released. The image goes to the player's inventory, and from there it can be used in other Roblox experiences or exported off platform.

The API reference describes the method as presenting a dialog where the player enters a name, enters a description, and previews the asset before submitting. It is a server-side call, marked as not thread safe, and it returns a PromptCreatePlatformContentResult plus the new asset ID on success.

That preview step is the part that does not exist on most inventory writes. A player has to look at what they made and confirm it before it becomes theirs. That is deliberate, and it is what makes the moderation model described further down possible.

How this differs from the makeup feature

The makeup announcement came four days earlier, on October 15, and it is easy to assume the two are the same thing. They are not, and the differences matter because they determine what you can actually build.
[th]Aspect[/th][th]In-experience makeup (Oct 15)[/th][th]Platform content images (Oct 19)[/th]

What players create	Eye, lip, and face makeup, eyelashes, eyebrows	Any EditableImage
Avatar type required	R15 with MeshPart heads only	None. Not an avatar feature
Requires creation tokens	Yes, one token per makeup item type	No
Revenue share	70% of sales after the creation advance is recouped (30% to the creator, 40% to the game)	None. Images are free to make
Resale and trading	Banned. Personal use only	Not applicable
Monetisation model	Paid creation, priced above the Marketplace price floor	Free player utility

The makeup path is a monetisation feature with a real price attached. It goes through AvatarCreationService:PromptCreateAvatarAssetAsync for a single asset, or the newer PromptCreateMakeupAsync when several layers are composited into one outfit. Both need Avatar Creation Tokens, which carry a recoupable creation advance plus a creation fee, and the game owner must hold a Roblox Plus or Premium subscription to qualify.

The image path has none of that machinery. No token, no advance, no subscription gate, no revenue split. It is a utility for letting players take something they drew in your game and keep it.

What you need to enable it

Two settings stand between you and a working build. Roblox's example code is blunt about both.

Your game must have the Allow Mesh / Image APIs setting turned on. Without it, CreateEditableImage() returns nothing and your publish call has nothing to upload.
You must test in a published place. Roblox notes that the prompt fails in an unpublished place in Studio, which trips up almost everyone the first time.
The call has to run on the server. If your drawing UI is a LocalScript, send the pixel buffer over a RemoteEvent and rebuild the EditableImage server-side before calling the prompt.
Validate the buffer before you use it. Roblox's own server example checks the type is a buffer and checks the length matches the expected size, then drops the request otherwise.

That last point is the one I would treat as a hard rule rather than an optimisation. A client can send you anything over a RemoteEvent, and the byte length is the cheapest thing to check. Roblox's reference implementation uses a 256 by 256 canvas, which is 262,144 bytes in RGBA, and rejects anything that does not match exactly.

Ownership, moderation, and the risks creators raised

Roblox states two things plainly in the announcement. Players fully own the content they publish and can do what they want with it, including exporting it or building another game with it. And persisted content may be moderated after the fact, so you should not assume the asset ID you get back will keep working.

That second line is the operational risk. You get an asset ID back from a successful call, and then moderation can pull the rug later. Anything that depends on that ID surviving should handle the asset disappearing.

The moderation flow has a safeguard worth knowing about. The image is shown in a CoreGui modal before the player confirms the save. Creators in the thread raised the obvious concern, which is what happens if a player publishes something offensive. Roblox staff answered that because the API forces the image through normal image moderation, a game that requires the image to be published before sharing it with other players should be fine from a free-form user content policy standpoint, though they said they would confirm with the policy team. Read that as likely-correct rather than guaranteed.

Two other questions from the thread had no answer at the time of writing. One creator asked whether images created this way can be archived, and what happens to asset privacy when a player has it restricted in Creator Hub settings. The same post flagged that a restricted asset may need the player to manually change it to Open Use in a browser before it displays in the game they just made it in. Roblox staff replied that they would check both with their team.

Why the general version matters

The makeup feature solves a specific problem for avatar customisation games. The general image API solves a broader one, and it removes a workaround a lot of creators have been maintaining.

One developer in the thread described building a full export workflow for a 3D building game, where players take their creations into Studio using a companion plugin and a base64 string. That is a lot of plumbing to move a player's own work out of your game. An in-game publish prompt replaces most of it.

Drawing games are the other obvious fit, and they have historically been stuck at 16+ because of free-form user content rules. The moderation-before-publish design is what changes that calculation, and it is the part Roblox has promised to confirm rather than something you should bank on today.

What is not in this release

Only EditableImages are supported. Roblox's own FAQ answers "Which asset type is coming next?" with a question back to the community, asking whether it should be audio or meshes. No mesh publishing, no audio publishing, and no committed timeline for either.

FAQ

Can players sell the images they publish?
Not through this API. Images published via PromptCreatePlatformContentAsync land in the player's inventory but are not Marketplace listings, and there is no price attached. The makeup path is different. It is paid, priced above the Marketplace price floor, and the creations still cannot be resold or traded.

Do I need Avatar Creation Tokens for this?
No. Tokens are a requirement of the in-experience creation and in-experience makeup creation APIs, such as PromptCreateAvatarAsync, PromptCreateAvatarAssetAsync, and PromptCreateMakeupAsync. The general image publishing method is not in that family.

Does the game owner need Roblox Plus or Premium?
The token-based creation APIs require the game owner to meet the Marketplace creator requirements, which include a Roblox Plus or Premium 1000/2200 membership. Roblox has not stated an equivalent subscription requirement for the image publishing method.

Can I pass a Decal instead of an EditableImage?
No. The object parameter currently accepts only an EditableImage, and assetType can only be AssetType.Image. Roblox staff explained the choice: a Decal is a combination of an asset and an image, the image is the underlying primitive, and they chose to upload the primitive.

Will my game get in trouble for what a player draws?
Roblox's position is that the API routes the image through normal image moderation before it becomes an asset, which is what gives them confidence that a game can require publishing before displaying user images. Staff said they would confirm the policy details with the policy team. Keep a report flow and do not display the image to other players before it has been published.

Is this the same as the October 15 makeup update?
No. They are separate announcements four days apart, with separate APIs, separate requirements, and different economics. The makeup feature is monetised and gated behind tokens and a subscription. The image API is free to use and has no token requirement.

Sources