Scratch Clones Explained: Why Duplicating Isn't Cloning

Last updated: October 2026

Scratch clones are temporary copies of a sprite that your code makes while the project runs, using create clone of [myself v]. Each clone runs whatever sits under when I start as a clone, and every clone vanishes when you click the green flag or the stop sign. Duplicating is different: it makes a permanent new sprite in the editor. Clone for many identical things, duplicate for different characters.

Most Scratch tutorials skip that distinction, and in my experience it is the one that makes clones click. Below is what each one is, how the three clone blocks work, and the counting mistake nearly every beginner makes.

Key Takeaways

• Duplicate in the editor, clone in the code. A duplicate is a permanent sprite with its own name and its own copy of the scripts. A clone exists only while the project runs and never appears in the sprite list.
• Three blocks do all the work. create clone of [myself v] makes the copy, when I start as a clone tells the copy what to do, and delete this clone removes it.
• The original is never a clone. It does not run when I start as a clone, and delete this clone does nothing to it. Forgetting this is where most miscounts come from.
• Scratch allows 300 clones at once. After that the create block silently does nothing, so every clone needs a way to delete itself.

What is a clone in Scratch?

The Scratch Wiki's page on cloning defines it as a feature that allows a sprite to create a copy of itself while the project is running. The last five words are the important ones. A clone does not exist until your code makes it, and it is gone the moment the project stops.

When a clone is created it copies its parent: position, direction, current costume, and the values of any "for this sprite only" variables. It also shares the parent's scripts. You do not write code for each clone separately. You write it once, under when I start as a clone, and every clone runs it.

That sharing is the whole point. Fifty raindrops, a stream of bullets, a swarm of bats for a Scratch horror game: each one is a clone running the same few blocks, and you only built one sprite.

If Scratch itself is new in your house, what Scratch is and how it works is the place to start. Clones usually arrive a few weeks in, once a child has built a couple of projects and wants more than one of something.

What is the difference between duplicating and cloning a sprite?

Duplicating happens in the editor, before the project runs. You right-click a sprite in the sprite list, choose duplicate, and Scratch makes a second sprite with a new name and its own copy of the costumes, sounds and scripts. From then on the two sprites are separate. Change one and the other stays as it was. The duplicate is saved with the project and is still there tomorrow.

Cloning happens in the code, while the project runs. The Wiki draws the line clearly: ordinary duplicates are permanent and appear in the sprite pane, whereas clones do not appear in the sprite pane.

	Duplicate	Clone
How you make it	Right-click the sprite, choose duplicate	The create clone of [myself v] block
When it exists	Permanently, saved with the project	Only while the project runs
Where you see it	In the sprite list, with its own name	On the stage only
Its scripts	Its own copy, edited separately	Shared with the original
How many	As many as you make by hand	Up to 300 at once in a project
Use it for	Characters that look or act differently	Many identical things: raindrops, bullets, coins

The practical test is one question. Do you want the copies to behave differently? Duplicate. Do you want many of the same thing? Clone.

Two projects already on this site show the duplicate side well. The Scratch platformer tutorial duplicates the ground sprite to make platforms, because each platform sits in its own place and never changes during the game. The two-sprite race in this animation speed experiment duplicates the cat, because the two cats need different numbers in their scripts. Neither would be better as clones.

One of my students, an 8-year-old beginner, met both ideas in his third session, alongside create clone of [myself v] and when I start as a clone. By the end of his first three lessons, clones and cloning versus duplicating were both on the list of things that were solid. I think it landed because the difference is so easy to see: one kind of copy shows up in the sprite list, the other never does.

How do the three clone blocks work?

create clone of [myself v] makes the copy. The dropdown can also name another sprite, and a clone can run this block too, which is how you get clones of clones, as the Create Clone of () page explains.

when I start as a clone is a hat block that runs the moment a clone is created. Only clones run it. The original sprite never does.

delete this clone removes the clone that runs it. The Cloning page notes that it does nothing if the original sprite runs it.

Try this with the default cat, and predict the result before you click the green flag:

• when green flag clicked
• go to x: (-200) y: (0)
• repeat (5), and inside it create clone of [myself v] followed by move (80) steps

How many cats will you see? The tempting answer is five. The real answer is six: five clones left behind in a row, plus the original, which kept walking and ended up at the far end. To check your count, download this example and open it in Scratch with File, then Load from your computer.

One more detail explains a lot of "my clone isn't working" moments. In Scratch's own source code, a new clone is placed behind the original, in exactly the same spot. So a clone that has not moved yet is hidden under its parent. Nothing is broken. Move either of them and the other appears.

Why do kids miscount their clones?

The same 8-year-old gave me the clearest example of this. He worked out that a ten-step move against a limit of seventy should produce seven copies. The first reaction in the lesson was to wave it off. That was the wrong call, and it nearly closed down the best thinking of the session.

A few minutes later it was tested properly, with a smaller limit. That is when he spotted his own off-by-one and realised the original sprite was not a clone. From then on he predicted the counts correctly.

There are two lessons in that for parents. First, when a child makes a prediction about code, run it rather than correcting it. A test they can see is worth more than an explanation they have to take on trust. Second, if the numbers are big, shrink them. Seven copies is hard to count on a busy stage. Two or three is easy, and the pattern is the same.

Lloyd, a parent whose 10-year-old daughter started with Scratch, wrote that "The tutor was patient and taught with a purpose." Patience in a Scratch lesson often looks exactly like this: running the child's idea instead of overruling it.

The other classic miscount is doubling. Suppose a sprite has when [space v] key pressed with create clone of [myself v] under it. Every clone responds to the space key too, because, as the Cloning page says, clones can respond to key press events and broadcasts. Press space once and you have 2 sprites. Press again and you have 4, then 8. The fix comes from the Wiki's guide to separating clone and sprite triggers: make a "for this sprite only" variable, set it to sprite under when green flag clicked and to clone under when I start as a clone, and only make a new clone if it says sprite.

How many clones can you have in Scratch?

300 at a time, across the whole project, not per sprite. The Cloning page gives the reason: the limit exists to prevent excessive lagging or crashes.

What happens at 300 surprises people: nothing. No error, no warning. In Scratch's source code, the function that makes a clone simply returns nothing when the limit is hit. The clones you already have carry on working. You just cannot make any more.

That is why the most common clone bug is a forever loop that makes a clone every time round and never deletes one. It works for a few seconds, then new clones stop appearing, and the child is convinced the code has broken. The fix is to give every clone a way to leave: delete this clone when it touches the edge, gets hit, or has done its job. The Delete This Clone page makes the same point: clones are not often meant to last until the green flag or stop sign is pressed.

Frequently Asked Questions

Why can't I see my clone? Usually because it is sitting directly behind the original, in the same spot. Scratch places each new clone behind its parent, so nothing seems to happen until one of them moves. And if the original was hidden when it made the clone, the clone starts hidden too, which is why a common pattern is to hide the original and put show under when I start as a clone.

Does a clone run the green flag script? No. Clicking the green flag removes every clone, so when green flag clicked only ever runs in the original sprite. Clones start their lives at when I start as a clone.

Can each clone have its own variables? Yes, if the variable is set to "for this sprite only". Each clone gets a copy of the original's value when it is created, and from then on its copy is its own. A "for all sprites" variable is shared by everyone, clones included.

What is the clone limit in Scratch? 300 clones at once in a project. When the limit is reached, create clone of [myself v] quietly does nothing and the existing clones keep running, so delete clones as soon as they are finished with.

Should I use clones or duplicates for enemies? Clones if the enemies are all the same, like a wave of identical bats. Duplicates if they are different, like a ghost that chases and a spider that drops from the ceiling. Plenty of games use both: a few duplicated enemy types, each of which clones itself.

Want your child's next clone idea tested, not waved off?

Clones are often the first place a Scratch project stops being one character and becomes a system, and it is exactly where a child's own predictions are worth running. That is the habit I build in every lesson: the child guesses, we test it, and the screen settles the argument. Book a free Discovery Call and bring your child's project with you.

Written by Michael Murr for Kids Coding Tutor: online 1-on-1 coding tutoring for children ages 8 to 16, from Scratch to Python to AI.