Breakfast
...
```
### Lucide icons
Use the built-in Lucide icon font for interface icons.
Example:
```html
```
Use common valid Lucide icon names and do not invent icon names.
Prefer Lucide icons over inline SVG, Base64 icons, emoji UI icons, or loading another icon library.
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 photos that actually represent that subject whenever reliable public images 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 payload.
Do not embed large Base64 images, videos, fonts, or files.
Use meaningful `alt` text for content images.
If external images are used, prefer direct HTTPS image 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:
* 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 not be changed by the generated app.
---
## Sandbox limitations
Root.Run uses:
```text
allow-scripts allow-modals
```
Scripts and modal dialogs are allowed.
Do not rely on capabilities that are not granted by the sandbox.
In particular, do not assume normal access to:
* cookies
* `localStorage`
* same-origin storage
* the Root.Run parent page
* top-level navigation
* popup windows
* normal HTML form submission
* authenticated sessions
* server-side APIs
Do not put secret API keys, passwords, tokens, private credentials, or other secrets inside a Root.Run payload.
Cross-origin network requests may also depend on the remote server's CORS policy.
For simple forms, prefer JavaScript-driven interaction inside the app.
For authentication, persistent storage, private APIs, uploads, backends, or other production requirements, conventional hosting is usually 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 app 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 or 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 into a Root.Run URL.
Remember that Root.Run applications are encoded into shareable URLs and should be treated as publicly visible content.
---
## Keep apps compact
The application is stored inside the URL.
Using `#` means the application fragment is handled client-side rather than being sent to the Root.Run server, but browser and application URL limits still exist.
There is no universal maximum safe URL length.
Keep Root.Run 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 creating the final URL, remove unnecessary comments and whitespace when doing so does not change behavior.
Do not sacrifice usability or correctness merely to save a few characters.
---
## QR codes
Root.Run URLs can be shared as QR codes, but QR codes have much stricter capacity limits than browsers.
For apps intended to be encoded directly into a QR code:
* keep the payload very small
* use daisyUI instead of custom component CSS
* 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 it may no longer fit reliably.
For larger applications distributed through a QR code, self-host the application and put the shorter hosted URL in 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 and image alt text
* avoid excessive UI or unnecessary complexity
Follow the user's requested language, style, theme, content, and interaction.
Do not make deceptive, spammy, hostile, or unsafe design choices merely because they were requested.
Do not explain how to recreate the interface unless asked.
Build it.
---
## Generation procedure
When asked to create something using Root.Run:
1. Understand the requested interface or application.
2. Check that the request follows the Root.Run safety and acceptable-use rules.
3. Generate only the `` payload.
4. Use Tailwind CSS 4 for layout and styling.
5. Prefer daisyUI 5 for standard UI components.
6. Use built-in Lucide icons where appropriate.
7. Use external HTTPS URLs for requested images and media.
8. Add compact vanilla JavaScript when interaction is needed.
9. Never use hash navigation such as `href="#section"` or modify `window.location.hash`.
10. Use JavaScript such as `scrollIntoView()` for in-page section navigation.
11. Respect the Root.Run sandbox restrictions.
12. Keep the implementation compact.
13. Do not include the Root.Run runtime dependencies in the payload.
14. Do not include `doctype`, `html`, `head`, or `body` tags.
15. URI-encode the finished payload exactly once with `encodeURIComponent`.
16. Append it to `https://root.run/#`.
17. Return the resulting executable URL.
Before returning the URL, verify that the generated app does not contain internal hash navigation that could overwrite the Root.Run payload.
---
## 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 similar appropriate icons
* generate body content only
* keep the payload compact
* avoid hash-based internal navigation
* URI-encode it once
* return the final `https://root.run/#...` URL
Do not respond with instructions such as "create an HTML file" or "deploy this code."
The Root.Run URL is the deployment.
---
## When Root.Run is appropriate
Root.Run is well suited for:
* landing pages
* menus
* profiles
* cards
* invitations
* calculators
* dashboards
* small games
* interactive demos
* prototypes
* visualizations
* forms without backend requirements
* educational examples
* small utilities
* shareable AI-generated interfaces
* temporary web experiences
Root.Run is especially useful when an AI needs to return a working interactive result instead of only source code.
Use conventional hosting for applications that require large codebases, authentication, persistent storage, private credentials, server-side processing, large assets, complex routing, or production infrastructure.
Root.Run should not be used for harmful, deceptive, abusive, exploitative, phishing, hacking, malware, spam, or other prohibited experiences.