Decide what readers can do

An embed is not a fixed widget. You build it from parts and leave out the ones your example does not need, which is how the same feature suits a one-line example and a full exercise.

The parts

• The editor. Where the code is. Leave it out entirely and you have a runnable example nobody can change.
• A run button. The thing readers press.
• Output. Where results appear.
• Input and standard input. For programs that read something before they do anything.
• An interactive toggle. Lets a reader answer the program as it runs rather than filling input in first.
• A language and version list. Turns one example into a comparison across languages.
• Libraries. For examples that need something beyond the standard library.

How much freedom to give

• Run only

  The code is yours and readers press play. Nothing they do changes what the next reader sees.

  Good for documentation, and any example that is meant to be exactly what you wrote.

• A scratchpad

  Readers rewrite whatever they like and run it.

  Good for teaching, exercises, and anywhere the point is trying it rather than reading it.

Neither costs the reader anything, and nothing they do is saved. An embed is not an account, so a reader who breaks the code fixes it by reloading.

What next

Once the embed is right, you can also drive it from your own page with a script.

Build the embed covers every element you can add and customise.