Conversor de HTML para MP4

The current pipeline was rebuilt specifically to eliminate the screen-share step. Earlier versions of the tool used getDisplayMedia() combined with MediaRecorder, which required the user to select a tab or window through the browser's native share dialog. That approach shipped with several intractable issues: the encoder returned errors at 1080p on some GPU configurations, the iframe sometimes rendered white if it mounted before the share stream was active, and the entire flow required explicit user interaction on every single capture. The replacement pipeline renders your HTML into a sandboxed iframe at the target dimensions directly inside the WikiPlus page, takes a rasterized snapshot of each frame using the html-to-image library via SVG foreignObject serialization, uploads each frame to an OffscreenCanvas, and pipes the frame data into the VideoEncoder API for H.264 encoding before final muxing with mp4-muxer. This all happens programmatically in your browser's JavaScript engine. No permissions dialog is needed because the tool is reading its own iframe's DOM, not a foreign tab. The output is a proper MP4 file with yuv420p color space and the faststart flag set, which means the moov atom is at the file head for immediate streaming playback. Practical tip: if your HTML uses external fonts, inline them as base64 data URIs in a style tag before pasting — cross-origin fonts are blocked by the iframe's sandbox policy and will be omitted from the rendered frames.

The static-HTML fast path reduces encoding time from roughly wall-clock duration to approximately 2 to 3 seconds for a standard 5-second clip at 1080p. The optimization works by detecting whether the HTML document contains zero running CSS animations, no video or canvas elements, and a stable DOM after the initial load. When all three conditions are met, the tool rasterizes the iframe exactly once using html-to-image, reuses that identical rasterized canvas as the pixel source for every frame in the encode sequence, and feeds the full batch to VideoEncoder without waiting for real-time playback. For a 5-second clip at 30 fps, this means 150 frames are encoded from the same source canvas in rapid sequence, limited only by VideoEncoder throughput and the backpressure cap of 2 pending frames. On a modern laptop CPU with hardware-accelerated H.264 encoding available through the VideoEncoder API, throughput is typically 50 to 150 frames per second, meaning the 150-frame batch completes in 1 to 3 seconds. On slower hardware without hardware encoder access, encoding falls back to software H.264, which runs at 10 to 30 fps, extending the total time to 5 to 15 seconds but still far faster than real-time. Practical tip: for HTML banners, infographic cards, and static email template previews — all common use cases for HTML to video conversion — the fast path covers virtually all scenarios and you should see consistent sub-5-second encode times.

CSS animations declared with @keyframes and the animation property are supported through a deterministic scrubbing mechanism. The tool pauses all document.getAnimations() on the iframe and advances each animation's currentTime by the inter-frame interval on every captured frame. This decouples the capture pipeline from real clock speed: regardless of how long the rasterization and encoding of each frame takes, the animation state always corresponds exactly to the virtual timestamp. CSS transitions, SVG animations via SMIL, and Web Animations API keyframes all participate in getAnimations() and are scrubbed correctly. JavaScript-driven animations that read Date.now() or performance.now() to calculate their position will not advance correctly because the tool does not mock the clock. Animations driven by requestAnimationFrame may also behave inconsistently since the frame loop is tied to the browser's real paint cycle rather than the virtual timestamp. Canvas-based animations are not captured at all — the iframe sandbox cannot serialize a live canvas element through SVG foreignObject. WebGL content also falls outside the capture path for the same reason. CSS features with partial fidelity include backdrop-filter, complex CSS filter chains, and some blend mode combinations that rely on compositor-layer processing. Practical tip: convert requestAnimationFrame animations to CSS keyframes or Web Animations API before capture, and replace canvas-based content with SVG or CSS equivalents to get deterministic, accurate frame rendering in the output MP4.

Frame rate and bitrate interact, and the right choice depends on what motion your HTML contains and where the video will be displayed. For static HTML or content with only gentle CSS transitions — fade-ins, slide-ins, opacity changes — 24 fps is sufficient and reduces file size compared to 30 or 60. The human eye cannot distinguish 24 from 30 fps for slow or stationary content. For smooth animations, scrolling effects, or any content with continuous motion, 30 fps is the standard for web video. 60 fps is worth using only for fast-moving animations where the motion blur between frames at 30 fps becomes visible — UI demonstrations, game interfaces, or rapid particle effects. For bitrate, the general guideline is: 720p at 30 fps works well at 2 to 3 Mbps. 1080p at 30 fps targets 5 to 8 Mbps for good quality. 1080p at 60 fps should have 8 to 12 Mbps. HTML content with flat colors, text, and geometric shapes compresses far better than photographic video, so you can often use the lower end of these ranges and see no visible difference. For social media exports — Instagram, TikTok, LinkedIn, YouTube Shorts — 1080p at 30 fps with 5 Mbps is a safe universal choice. For email embedding or banner ads where file size matters, 720p at 24 fps with 2 Mbps balances quality and transfer speed. Practical tip: render a 5-second test clip at your target settings and check the file size before committing to a full-length render.

WikiPlus does not add watermarks to any output file from any tool. The MP4 you download is a clean file containing only the content you encoded — no logo overlay, no text burn-in, no metadata tag identifying it as tool-generated. There is no account requirement, no subscription paywall, and no daily download cap. You can generate and download as many MP4 files as your session needs. The practical length limit is set by your browser's memory budget. The tool holds the full encoded output in memory as a Blob before offering the download. A 5-minute 1080p30 clip at 5 Mbps produces approximately 188 MB of encoded data. Most browsers allocate 2 to 4 GB per tab for Blob storage on desktop systems, which accommodates approximately 10 to 20 minutes of 1080p output. Attempting to generate clips beyond that may cause the tab to run out of memory and terminate the encode. For long HTML presentations or multi-minute animated sequences, encode in segments of 2 to 3 minutes and concatenate them locally with FFmpeg using the concat demuxer. Everything runs locally in your browser. The encoded video bytes never leave your device and are not stored on any server. Practical tip: set the duration field to the exact length of your content rather than a round number — encoding 47 seconds instead of 60 saves 21 percent of encoding time and file size, which compounds when generating multiple variations of the same HTML design.