# How to Use Broadcast in Scratch: Messages Explained
Author: Arpita Jain
Author URL: https://www.codeyoung.com/blog/author/arpita-jain
Published: 2026-10-20
Category: Coding For Kids & Teens
Category URL: https://www.codeyoung.com/blog/category/coding-for-kids-and-teens
Meta Title: How to Use Broadcast in Scratch: Messages Explained
Meta Description: Broadcast in Scratch lets every sprite react to one event. The message carries no data, and sending it twice silently restarts the receiving script.
Tags: Coding For Kids, Scratch For Kids, Game Development For Kids, Scratch Programming, Coding Lessons
Tag URLs: Coding For Kids (https://www.codeyoung.com/blog/tag/coding-for-kids), Scratch For Kids (https://www.codeyoung.com/blog/tag/scratch-for-kids), Game Development For Kids (https://www.codeyoung.com/blog/tag/game-development-for-kids), Scratch Programming (https://www.codeyoung.com/blog/tag/scratch-programming), Coding Lessons (https://www.codeyoung.com/blog/tag/coding-lessons)
URL: https://www.codeyoung.com/blog/scratch-broadcast-blocks

A Scratch project with six sprites and no messages is six small programs that cannot talk to each other. Everything happens when the green flag is clicked, nothing happens in a sequence, and the first time a child tries to build a game with levels the whole thing falls apart. **Broadcast in Scratch** is the block that fixes that, and it is the point where a child stops writing scripts and starts writing a program.

For parents: this is a genuine milestone rather than another block to learn. Coordinating several independent things that all react to one event is the same idea behind events in JavaScript, signals in Python and messages between services in professional software. A child who understands broadcast has met that concept years before they meet the vocabulary.

Two parts of how broadcast works surprise almost everybody, including adults who have used it for years. A message carries no information at all, and sending the same message twice in quick succession silently restarts the script that was listening. Both are covered below, with what to do instead.

## What does broadcast do in Scratch?

It sends a named message that every sprite and the stage hears at the same moment. The Scratch Wiki puts it plainly: a broadcast is "a message that is sent through the Scratch program, activating scripts with the matching hat blocks". Any script anywhere in the project that begins with a matching `when I receive` block starts running.

Three blocks do the work, and all three live in the yellow Events category.

BlockWhat it doesUse it when`broadcast [message]`Sends the message and carries straight on to the next blockThe sender has nothing to wait for`broadcast [message] and wait`Sends the message and pauses until every listening script has finishedThe next step depends on the receivers being done`when I receive [message]`A hat block that starts a script when the message is heardOn every sprite that needs to react![Diagram showing one Scratch broadcast start game block and three sprites each running a when I receive start game block with a different action](https://prod.superblogcdn.com/site_cuid_clvc4016q001j13bhaleswmt1/images/scratch-broadcast-one-message-three-sprites-1792659169437-compressed.png)One sender, three listeners, no connections drawn. The sprites are linked only by the message name matching exactly, which is why a typo in a message name produces silence rather than an error.

## How do you send your first broadcast?

Six steps, and a child can follow them unaided. The expected result is stated at each stage so they know it worked.

1. Click the sprite that should send the message.
2. Open the **Events** category, the yellow one, and drag a `broadcast` block into the code area.
3. Click the dropdown arrow on the block and choose **New message**.
4. Type a name that says what happened, not what should happen next. `player scored` is a good name. `make the ball hide` is a poor one, because two years later a second sprite will want to react to the same event differently.
5. Click a different sprite, open Events again, and drag out `when I receive`. Pick your message from its dropdown. Snap one action block underneath, such as `hide`.
6. Click the `broadcast` block directly to fire it by hand. The second sprite should react at once. If nothing happens, the two blocks are almost certainly set to different messages.

Naming matters more than it looks. A message name describes an event that has happened, which lets any number of sprites decide for themselves how to respond. Children who name messages after one sprite's reaction end up with twelve nearly identical messages and a project nobody can edit.

## A broadcast carries no information

This is the part that costs the most time, and it is almost never mentioned in tutorials. **Broadcasts cannot carry values.** A message has a name and nothing else. There is no slot for a number, no second field, no way to attach the score or the level or which sprite was touched.

So a child who builds `broadcast [player scored 5]` has not sent the number five anywhere. They have created a message whose name happens to contain the character 5, and if the next score is 10 they will create a second message, then a third. Projects built this way accumulate dozens of messages and still cannot add up a score.

### The workaround, and it is the standard one

Set a variable first, then broadcast. The variable must be available to all sprites so the receiver can read it.

1. Make a variable using **For all sprites**, for example `points this hit`.
2. In the sending sprite: `set points this hit to 5`, then `broadcast player scored`.
3. In the receiving sprite: `when I receive player scored`, then `change score by points this hit`.

Set the variable _before_ the broadcast, never after. The receiving script may start running the instant the message is sent, so a variable set on the following line can be read too late. Variable scope is the other half of this topic and it has its own trap with clones, which we covered in detail in [how to make a score counter in Scratch](https://www.codeyoung.com/blog/scratch-score-counter).

## broadcast versus broadcast and wait

Both blocks send the identical message to the identical listeners. The only difference is what the _sender_ does next. Plain `broadcast` moves to its next block immediately. `broadcast and wait` stops and does nothing until every script under a matching `when I receive` block has finished, then continues.

![Comparison of the Scratch broadcast and broadcast and wait blocks showing the waiting version pausing the sending script until receivers finish](https://prod.superblogcdn.com/site_cuid_clvc4016q001j13bhaleswmt1/images/scratch-broadcast-versus-broadcast-and-wait-1792659177504-compressed.png)Identical blocks, different timing. The waiting version is longer by exactly the time the receivers take, which is why a level-setup sequence built on plain broadcast often runs in the wrong order.

A worked case makes the choice obvious. Suppose the stage should announce a level, wait for three sprites to move into position, and only then start the timer.

- With `broadcast set up level` the timer starts immediately, while the sprites are still moving. The game begins before the board is ready.
- With `broadcast set up level and wait` the stage pauses until all three sprites have finished moving, then starts the timer. Correct every time, with no guesswork about how long to wait.

Children reach for a `wait 1 seconds` block to solve this, which works on their laptop and fails on a slower one. The waiting version of broadcast is the honest fix because it waits for the actual work rather than for a guessed duration. If you are adding a timer to a project, [making a timer in Scratch](https://www.codeyoung.com/blog/how-to-make-a-timer-in-scratch-step-by-step-timer-tutorial-for-students) walks through the timing blocks themselves.

## Why does your script restart and never finish?

Because a second message interrupts the first. The Scratch Wiki is explicit: "If the same message is sent again while the script is still running, the script will restart without reaching the blocks at the end."

That behaviour produces one of the hardest bugs a young coder meets, because there is no error, no red glow and no message. Consider a level-setup script that switches the backdrop, waits two seconds, shows the boss and sets lives to three. If anything broadcasts `next level` again during that two-second wait, the script jumps back to the top. The boss never appears and lives are never set. The project simply sits there looking broken.

![Diagram of a Scratch when I receive script restarting from the top when the same message is sent again, with the final two blocks never reached](https://prod.superblogcdn.com/site_cuid_clvc4016q001j13bhaleswmt1/images/scratch-broadcast-restart-never-reaches-end-1792659220025-compressed.png)The last two blocks are never reached. Any wait block inside a receiving script is a window during which a repeat message can discard everything below it.

Three habits prevent it. Keep `wait` blocks out of receiving scripts wherever you can. Guard a message that must not re-fire with a variable, for example setting `level loading` to 1 and checking it before broadcasting again. And put the blocks that matter most, such as setting lives, near the top of the script rather than the bottom, so an interruption costs less. Reading a project for this kind of silent failure is a skill worth teaching directly, which is why we wrote [debugging as a taught skill](https://www.codeyoung.com/blog/teaching-kids-debugging).

## Do clones receive broadcasts?

Yes, all of them, at once. If a sprite holding a `when I receive` block has clones, the code under that block runs for the original sprite and for every clone it has made. Nothing extra is needed to make that happen.

That is genuinely useful. One `broadcast game over` can hide forty falling apples, stop every enemy and reset the player, with no list of clones to manage and no loop to write. It is also the cleanest way to delete clones: give every clone a `when I receive game over` script ending in `delete this clone`.

One caution. Scratch runs broadcasts for sprites and clones in the order they are layered front to back, and the Wiki describes that ordering as implementation dependent and says it should not be relied on in projects. So never build a game whose logic depends on which clone reacts first. If order matters, number the clones with a variable set at creation and have each one check its own number.

## Broadcast in a real game

A catching game with a score, three lives and two levels needs about four messages, and no more.

MessageSent byWho listens, and what they do`start game`Stage, after the green flagBasket moves to centre, apples begin falling, score resets to 0`apple caught`The apple clone that touched the basketStage adds to the score and checks whether the level target is met`apple missed`The apple clone touching the floorStage removes a life and checks whether lives have reached 0`game over`Stage, when lives reach 0Every apple clone deletes itself, basket hides, final score shows

### Why the stage should do the deciding

Notice that every message is named after something that happened, and that the stage does all the deciding. Sprites report events, one script decides what they mean. That single rule keeps a project readable as it grows, and it is the same separation that professional programs use. If your child is still building their first game, [how to make a game on Scratch](https://www.codeyoung.com/blog/how-to-make-a-game-on-scratch) covers the groundwork these messages sit on top of.

Not sure which level your child should start at? A free trial class with a Codeyoung
teacher shows you exactly where they are and what they are ready for next, before you
commit to anything.

[Book a Free Trial →](https://book-a-demo.codeyoung.com?utm_source=blog&utm_medium=codeyoung&utm_campaign=scratch-broadcast-blocks)

## When a broadcast seems not to work

Work down this list in order. In our experience the first item accounts for most cases.

1. **The two message names are different.** Scratch will not warn you. Open both dropdowns and confirm they show the same entry rather than two similar ones.
2. **The receiving script is on the wrong sprite.** A `when I receive` block sitting on the sender does fire, but if you expected a different sprite to move, nothing visible happens.
3. **The message fires before the listener exists.** A clone created after the broadcast was sent never hears it. Broadcasts are not stored and replayed.
4. **A second broadcast is restarting the script.** Add a temporary `say` block as the final block. If it never speaks, the script is being interrupted.
5. **The variable was set after the broadcast, not before.** The receiver read the old value.
6. **The sprite is hidden or off-screen.** The script ran correctly and you cannot see the result.

### What to try next

Once messages are comfortable, the natural next projects are a level system, a pause menu and a high-score display, all three of which need broadcast and a variable working together. Children who are confident with both are usually ready to think about text languages, and [when a child is ready to leave Scratch](https://www.codeyoung.com/blog/ready-to-leave-scratch) sets out the signals worth watching for.

## The short version

Broadcast is how separate parts of a Scratch project agree on what is happening. Name messages after events, set any variable the receiver needs _before_ sending, and use `broadcast and wait` whenever the next step depends on the listeners finishing. Remember that a message carries no data and that a repeat message restarts whatever was listening, because those two facts explain most broadcast bugs a child will ever hit.

It is also the moment a child's projects stop being one script long. That is worth noticing when it happens.

Codeyoung runs 1:1 live online classes for children aged 6 to 17, with a teacher who
adapts the pace to your child rather than a fixed syllabus. The first class is free, so
you can see how they respond before deciding.

[Book a Free Trial](https://book-a-demo.codeyoung.com?utm_source=blog&utm_medium=codeyoung&utm_campaign=scratch-broadcast-blocks)

Block behaviour verified against the [Scratch Wiki broadcast documentation](https://en.scratch-wiki.info/wiki/Broadcast) and the [Scratch Foundation](https://www.scratchfoundation.org/) on 21 October 2026. Our [Scratch coding classes for kids](https://www.codeyoung.com/coding/scratch-coding-classes-for-kids) teach messages and variables together, because most projects need both at once.
## FAQs
Q: What does broadcast do in Scratch?
A: A broadcast sends a named message that every sprite and the stage can hear at the same time. Any script that starts with a matching when I receive block runs. The Scratch Wiki describes it as a message sent through the program that activates scripts with the matching hat blocks, so it is the standard way to make separate sprites react to one event.

Q: Can a Scratch broadcast send a number or a value?
A: No. Broadcasts cannot carry values, only a name. If a sprite needs to send a number, set a variable that is available to all sprites first, then broadcast the message. The receiving script reads the variable when it runs. This is the single most common reason a broadcast appears to lose information.

Q: What is the difference between broadcast and broadcast and wait?
A: The plain broadcast block sends the message and immediately continues to the next block. Broadcast and wait sends the message and pauses that script until every script under a matching when I receive block has finished. Use the waiting version when the next step depends on the receivers completing their work.

Q: Why does my Scratch script restart when I broadcast again?
A: Because that is how the when I receive hat block behaves. The Scratch Wiki states that if the same message is sent again while the script is still running, the script will restart without reaching the blocks at the end. A second message sent during a wait block silently throws away everything after it.

Q: Do clones receive broadcasts in Scratch?
A: Yes. If a sprite containing a when I receive block has clones, the code under that block runs for the original sprite and for all of its clones. That makes broadcast a clean way to tell every clone to do something at once, such as hiding them all when a level ends.

Q: What age can a child start using broadcast blocks?
A: Most children who can already build a working one-sprite project are ready, which is usually around age eight to ten. Broadcast is the step where a child moves from a single script to a coordinated program, so it helps to introduce it when their projects have outgrown one sprite rather than before.




---
This blog is powered by Superblog. Visit https://superblog.ai to know more.
---