> ## Documentation Index
> Fetch the complete documentation index at: /llms.txt
> Use this file to discover all available pages before exploring further.
# Render a video to MP4
> Review the project, run its checks, render through an agent, the browser editor, or the CLI, and deliver the right file or link.
Finish the same editable project through your agent, the browser editor, or the command
line. The route can change; the quality gate does not.
## 1. Approve the project, not one good frame
Watch the complete preview from the beginning. Check the message and sequence
before spending time on small visual details.
* Does the opening make the subject clear soon enough?
* Does every scene add something?
* Can text, captions, and product screens be read at delivery size?
* Do narration, visuals, music, and sound effects arrive together?
* Does the ending finish cleanly and make the next action clear?
## 2. Run the project checks
Run the checks in the browser editor, ask your agent to run them, or use:
```bash
npx hyperframes lint
npx hyperframes check
```
`lint` catches composition-structure mistakes. `check` runs lint plus browser,
runtime, layout, motion, and WCAG contrast verification.
Checks cannot judge the story for you. Fix technical failures, then watch the
project again if a fix changed what the viewer sees.
## 3. Render from where you are working
All three paths render the same source.
### Ask the agent
```text
Run the HyperFrames checks, fix any failures, and show me the final preview.
When I approve it, render an MP4 to renders/final.mp4.
```
Use the agent when a failed check may require a source change or when you want
one person to manage the complete finish. The `/hyperframes` skill waits for
render approval after the final preview.
### Use the browser editor
Open **Export**, choose the destination's format and size, and start the render.
The Renders panel shows progress and keeps completed files available to
download.
The browser editor checking and rendering the same project shown in its editor.
### Use the CLI
```bash
npx hyperframes render --output renders/final.mp4
```
Use the CLI for a direct local render, a script, CI, or a repeatable batch. The
installed version remains authoritative: run
`npx hyperframes render --help` for every available option.
## 4. Choose what the destination needs
MP4 at the project's authored size is the normal delivery choice. Ask for
another format or resolution only when the next tool or platform requires it.
| Need | Start with |
| - | - |
| Watch, upload, or publish a normal video | MP4 |
| Place a transparent overlay on the web | WebM with an alpha-compatible composition |
| Continue in a professional editing tool | MOV, usually ProRes |
| Deliver a specified high-resolution master | The matching 4K preset |
Higher output resolution does not add detail to low-resolution media. A higher
frame rate creates more frames; it does not improve motion authored for a lower
cadence.
Use [export in the browser editor](/studio/export.md) for its visible controls or the
[rendering reference](/guides/rendering.md) for formats, Docker, batch output, and
advanced CLI behavior.
## 5. Watch the rendered file
Open the output itself instead of relying on the preview.
* Watch the first and final seconds.
* Check captions, cuts, and the most complex transition.
* Listen for clipped narration, late sound effects, or an abrupt music ending.
* Confirm duration, dimensions, format, and audio.
* Use a filename that identifies the project and version.
The preview proves the project can play. The exported file proves the delivery
is correct.
## 6. Share the right form
| The recipient needs | Send |
| - | - |
| A video to watch or upload | The rendered MP4, WebM, or MOV |
| A browser link to the current project | A published project URL |
| The ability to continue editing | The source project and its assets |
Publish the project when a browser link is more useful than a file:
```bash
npx hyperframes publish
```
The command uploads the project and returns a stable URL. An anonymous first
publish creates a claimable link. Sign in when the CLI should own the project
immediately, update an existing link, or publish into a shared space.
A local video poster referenced with a relative path, such as
`../shared/poster.png`, is copied into the published project even when it lives
outside the project directory. Percent-encoded paths work too, such as
`../shared/poster%20art.svg` for `poster art.svg` or
`../shared/%E5%B0%81%E9%9D%A2.svg` for `封面.svg`.
Local images outside the project referenced by an `` or `` element's
`srcset` are included too. Their size or pixel-density descriptors are preserved,
and your source files stay unchanged.
Before sharing source, remove secrets and confirm that every included media file
can be shared. Tell a reviewer whether you need feedback on story, visuals,
timing, facts, or final approval.
## If the finish fails
Keep the first exact error and run:
```bash
npx hyperframes doctor
npx hyperframes lint
npx hyperframes check
```
Use [Troubleshooting](/help.md) for project and render failures,
or [Browser editor troubleshooting](/help.md#in-the-preview-and-browser-editor) when the problem is in the
editor or its render queue.
## Related topics
* [Export and manage renders in the browser editor](/studio/export.md)
* [Use advanced rendering options](/guides/rendering.md)
* [Diagnose a project or render failure](/help.md)
## Share from the local Studio preview
Open a project with `hyperframes preview`, then choose **Share** beside **Export**.
Choose **Sign in** if prompted. You can also run
`hyperframes auth login` in your terminal, then return to Studio. Sharing reconnects
automatically after browser sign-in or when you return to the panel. Credentials stay
in the local CLI process. If you switch accounts in the terminal, reload Studio
or sign in from the panel before retrying.
Choose the workspace and who can access the project, then choose **Create share
link**. Studio finishes saving pending edits before it renders and uploads the
project. The five free shared-project allowance is the same allowance used by
Desktop and the CLI. The workspace meter comes from the server; retries of an
existing registration do not need an extra slot.
Project files are included when available for the workspace. The panel reports
whether the last Studio upload included files or was video only. If attaching
files fails, retry the upload or explicitly choose **Retry with video only**.
When the video is ready, choose **Copy link**. Local edits do not automatically
replace the shared video: **Update shared version** uploads the saved project to
the same review page. Changes to access use a separate **Save access** action.
**Turn link off** keeps the project and comments; updating the video keeps an
off link off. Turning the link off does not free a shared-project slot.
You can close the Share panel while sharing continues, but keep the local Studio
server running. Reopen the panel to recover progress, or use **Refresh** after a
connection problem. **Manage sharing** opens the web page for invites and owner
settings. Existing published project URLs continue to open separately.
The local sharing bridge is available only from the same-origin loopback Studio
page. It does not expose CLI credentials or accept a different project path.
As with local preview, open projects whose scripts you trust.