Hello Root.Run
Breakfast
...
```
### Lucide icons
Use the built-in Lucide icon font for interface icons.
Example:
```html
```
Use common valid Lucide icon names.
Do not invent icon names.
Prefer Lucide icons over:
* inline SVG
* Base64 icons
* emoji used as interface icons
* additional icon libraries
This keeps Root.Run payloads smaller.
---
## Images and media
Images, video, fonts, and other public resources may be loaded from external HTTPS URLs.
When the user asks for photos, use relevant public image URLs.
When a specific real business, product, place, person, or subject is requested, use media that actually represents that subject whenever reliable public resources are available.
Do not silently substitute unrelated stock photography when the user expects real imagery.
Example:
```html
```
Prefer external assets over embedding them into the Root.Run payload.
Do not embed large:
* Base64 images
* videos
* fonts
* binary files
Use meaningful `alt` text for content images.
Prefer direct HTTPS media URLs from reliable public sources.
---
## JavaScript
Vanilla browser JavaScript is supported.
Example:
```html
0
```
Use JavaScript when interaction is needed, but keep it compact.
Prefer browser APIs and simple JavaScript over adding frameworks or libraries.
External browser libraries may be loaded from a public CDN when genuinely necessary.
Do not assume access to:
* Node.js
* npm
* a bundler
* a build step
* a filesystem
* server-side code
Remember that `window.location.hash` is reserved for the Root.Run payload and must never be changed by the generated app.
---
## Sandbox limitations
Root.Run executes generated applications inside a sandboxed iframe.
Scripts and modal dialogs are supported.
Do not rely on capabilities that are unavailable or restricted by the sandbox.
In particular, do not assume normal access to:
* cookies
* `localStorage`
* same-origin storage
* the Root.Run parent page
* unrestricted top-level navigation
* popup windows
* normal HTML form submission
* authenticated sessions
* server-side APIs
Do not put secret API keys, passwords, access tokens, private credentials, or other secrets inside a Root.Run payload.
Cross-origin network requests may depend on the destination server's CORS policy.
For simple forms, prefer JavaScript-driven interaction inside the application.
For authentication, persistent storage, private APIs, uploads, backends, server-side logic, or other production infrastructure requirements, conventional hosting is generally more appropriate.
---
## Safety and acceptable use
Root.Run should be used to create useful, creative, educational, entertaining, or legitimate commercial experiences.
Do not generate a Root.Run application whose purpose is harmful, abusive, deceptive, exploitative, or illegal.
### Hate and harassment
Do not create content that promotes hatred, dehumanization, discrimination, harassment, or violence against people based on protected characteristics such as race, ethnicity, nationality, religion, sex, disability, or similar identity characteristics.
Do not create targeted harassment, humiliation, threats, or abuse.
### Religion
Do not create content whose purpose is to insult, degrade, mock, harass, or incite hostility against a religion or its followers.
Respectful religious content, comparative religion, historical discussion, educational material, and good-faith criticism or discussion of beliefs and institutions are allowed when presented without hatred or abuse.
### Violence and harm
Do not create experiences intended to facilitate:
* violence
* physical harm
* abuse
* self-harm
* dangerous wrongdoing
* criminal activity
* exploitation
* financial harm
Do not create tools whose primary purpose is to help someone injure, threaten, exploit, or endanger another person.
### Sexual content and abuse
Do not create pornographic, sexually explicit, erotic, sexually exploitative, or sexual-service content.
Never create sexual content involving minors.
Never create content depicting, promoting, facilitating, or normalizing sexual abuse, exploitation, coercion, or non-consensual sexual activity.
### Phishing, hacking, and malware
Never create:
* phishing pages
* fake login pages
* credential-harvesting forms
* deceptive account-verification pages
* malware
* malicious downloads
* exploit tools
* unauthorized access tools
* interfaces intended to steal passwords, tokens, payment information, or private data
Do not imitate a real website, company, bank, government service, social network, or authentication page in a way intended to deceive users.
Security-related educational interfaces must not be designed to enable real-world abuse or unauthorized access.
### Scams and deception
Do not create:
* scam pages
* fraudulent investment pages
* fake giveaways
* fake payment pages
* deceptive checkout pages
* impersonation pages
* counterfeit support pages
* misleading urgency
* false claims intended to manipulate users
Clearly distinguish fictional demonstrations from real services when confusion could cause harm.
### Spam
Do not create spammy webpages or experiences.
Avoid:
* keyword stuffing
* repetitive promotional content
* deceptive buttons
* fake notifications
* fake download buttons
* excessive popups
* misleading calls to action
* unsolicited bulk-message generators
* pages designed mainly to manipulate search engines or users
A Root.Run page should provide genuine value rather than merely attract clicks.
### Privacy
Do not expose, collect, publish, or facilitate misuse of private or sensitive personal information.
Do not create interfaces designed for stalking, doxxing, covert tracking, credential theft, or unauthorized surveillance.
Never place private credentials or sensitive personal data directly inside a Root.Run URL.
Root.Run applications are stored inside shareable URLs and should be treated as publicly visible content.
---
## Keep apps compact
The application is stored directly inside the URL.
Using `#` means the application fragment is handled client-side rather than normally being sent to the Root.Run server, but browser, application, platform, messaging, and URL-length limitations still exist.
There is no universal maximum safe Root.Run URL length.
Keep payloads compact.
Prefer:
* daisyUI components
* Tailwind utilities
* Lucide icons
* semantic HTML
* concise JavaScript
* external image and media URLs
* browser-native functionality
Avoid:
* large custom stylesheets
* duplicated markup
* inline SVG icons
* Base64 assets
* large datasets
* embedded fonts
* bundled frameworks
* unnecessary comments
* generated boilerplate
* verbose abstractions
Before producing the final URL, remove unnecessary comments and whitespace when doing so does not affect behavior.
Do not sacrifice usability, accessibility, or correctness merely to save characters.
---
## QR codes
Root.Run URLs can be shared as QR codes, but QR codes have much stricter capacity limits than browsers.
For applications intended to be encoded directly into a QR code:
* keep the payload very small
* use daisyUI instead of large custom component styles
* use Lucide instead of SVG icons
* use external images instead of embedded images
* minimize markup and JavaScript
* avoid unnecessary text and data
Small Root.Run utilities, menus, cards, demos, games, forms, and interactive experiences can work well this way.
As the URL grows, the QR code becomes denser and harder to scan, and eventually may no longer fit reliably.
For larger applications distributed through a QR code, self-host the application and place the shorter hosted URL inside the QR code instead.
---
## Design behavior
When a user asks Root.Run to create an interface, produce a finished interface rather than a bare technical demonstration.
Unless the user specifies otherwise:
* make it responsive
* make it visually polished
* use good spacing and hierarchy
* use appropriate daisyUI components
* use Tailwind for layout and refinement
* use Lucide icons where useful
* use requested photos or media
* support mobile screens
* use accessible labels
* use meaningful image alt text
* avoid unnecessary UI complexity
Follow the user's requested:
* language
* content
* style
* theme
* interaction
* layout
* branding
Do not explain how to recreate the interface unless asked.
Build it and return it as a Root.Run URL.
---
## Generation procedure
When asked to create something using Root.Run:
1. Understand the requested interface or application.
2. Check that the request follows Root.Run's safety and acceptable-use rules.
3. Build the finished interface, not merely an example or tutorial.
4. Generate only content intended to live inside the document ``.
5. Use Tailwind CSS 4 for layout and styling.
6. Prefer daisyUI 5 for standard UI components.
7. Use built-in Lucide icons where appropriate.
8. Use external HTTPS URLs for requested images and media.
9. Add compact vanilla JavaScript when interaction is needed.
10. Never use hash navigation such as `href="#section"`.
11. Never modify `window.location.hash`, `location.hash`, or equivalent fragment navigation.
12. Use `scrollIntoView()` or another JavaScript method for in-page navigation.
13. Respect Root.Run sandbox restrictions.
14. Keep the implementation reasonably compact.
15. Do not include Root.Run runtime dependencies in the payload.
16. Do not include `doctype`, `html`, `head`, or `body` tags.
17. Finish the complete body payload before encoding.
18. URI-encode the complete payload exactly once using `encodeURIComponent()` semantics.
19. Append the encoded payload to:
```text
https://root.run/#
```
20. Return the resulting executable Root.Run URL.
Before returning it, verify:
* the URL begins exactly with `https://root.run/#`
* the payload was encoded exactly once
* the payload does not contain a complete HTML document
* the application does not use internal hash navigation
* the application does not modify `window.location.hash`
* the result is not a `data:` URL
* the result is not raw source code
* the result is not another hosting service
If the user requested a single line, output exactly one line containing the Root.Run URL.
---
## Example request
User:
> Create a menu containing 3 breakfast dishes, with photos and icons using Root.Run.
Expected behavior:
* create a polished responsive breakfast menu
* include exactly 3 dishes
* use relevant external food photos
* use daisyUI cards or another appropriate daisyUI layout
* use Tailwind for spacing and responsive layout
* use built-in Lucide icons such as food, clock, star, or other appropriate icons
* generate body content only
* keep the payload compact
* avoid hash-based internal navigation
* encode the complete payload once
* return the final `https://root.run/#...` URL
The response should end with the executable Root.Run URL.
If no explanation was requested, the preferred response is simply:
```text
https://root.run/#