DFM2HTML FAQ: Answers to Common Questions

DFM2HTML runs on Windows 7 SP1 and later, including Windows 8, 8.1, 10, and 11. Both 32-bit and 64-bit editions are available from the download page. Most machines sold after 2010 are 64-bit. You can check by opening Settings, then System, then About on your machine to confirm your system type.

A per-user install does not require administrator privileges. If you want to install for all users on a shared machine, administrator access is needed. The per-user option is the most common choice for personal and small business use. The installer will prompt you for the installation scope during setup.

The default installation path depends on the scope you choose. A per-user install places files under your user profile's AppData directory. An all-users install places files in the standard Program Files directory. You can customize the path during setup, but the defaults work well for most configurations.

Yes. You can install and run the editor on multiple machines. Your project files are standard folders containing HTML, images, and assets, so you can move them between machines using a USB drive, file sync service, or network share without any special export or import step.

DFM2HTML is distributed as a standard Windows installer from the official download page. It does not bundle toolbars, adware, or third-party software. The installer does exactly what it says: it places the editor files on your system and creates the expected shortcuts. No background services run after installation, no telemetry is collected, and no network calls are made during or after setup. If your antivirus flags the installer, it is a false positive caused by the self-extracting archive format. You can verify the download by checking the file size against the values listed on the download page.

DFM2HTML exports standard HTML files along with CSS stylesheets, JavaScript files for menus and interactive behavior, and all referenced images and assets. The output is a complete set of static web files that work on any web server without server-side processing, database connections, or runtime dependencies. You get a folder of files that you upload directly.

Yes. The exported HTML follows standard document structure with proper nesting and clean formatting. You can open any exported file in a text editor and make manual adjustments. Keep in mind that if you re-export from the visual editor later, your hand edits in the output folder will be overwritten unless you maintain those changes separately or make them in a copy.

The export panel gives you configuration options for how CSS is handled. You can choose between linked external stylesheets and inlined CSS depending on your hosting situation and preference. External stylesheets are the standard recommendation because they allow caching and keep the HTML cleaner, but inline CSS can be useful for single-page projects or email-compatible output.

The export workflow processes the full project to ensure all internal links, shared assets, and navigation structures stay consistent. If you only need to update a single page on your server, you can export the full project and then upload just the changed HTML file and any updated assets. The directory structure and filenames remain stable between exports, so a selective upload is straightforward.

For sites with fewer than ten pages, a single column layout keeps things simple and manageable. For documentation or reference sites, a two column layout with sidebar navigation helps visitors orient themselves. For sites where persistent navigation is important, frame-based templates keep the menu visible at all times. The template library includes anatomy breakdowns and guidance for each structure so you can compare options before committing.

Switching templates mid-project is possible but requires care. The template defines the structural skeleton of your pages, including column count, navigation placement, and content flow. Changing that skeleton means your content blocks need to be repositioned within the new structure. For small projects this is manageable. For larger sites with many pages, it is better to make the template decision early. If you are unsure, start with a single column layout. It is the easiest to migrate from later.

Every template can be customized after selection. Templates define structure, not visual style. You control colors, fonts, spacing, and background settings through the editor's property panels. The template gives you the bones; you decide everything else about the appearance.

Minor rendering differences between the editing canvas and a production browser are normal and expected. Font smoothing, sub-pixel alignment, and spacing calculations can vary between the editor's internal rendering engine and specific browser versions. The built-in preview mode uses an embedded browser view that gives you a more accurate representation. Always preview before exporting, and test the final output in Chrome and Firefox before publishing.

Check whether the issue involves CSS features that have inconsistent support across browsers. Common culprits include specific font rendering, box model differences in older browser versions, and JavaScript event handling variations. The HTML output from DFM2HTML targets broadly supported standards, but edge cases exist. If a specific element breaks, simplify the structure for that element and test again. The extended FAQ covers browser-specific troubleshooting in more detail.

Templates provide responsive behavior out of the box. The level of mobile adaptation depends on the template you choose. Single column layouts translate well to narrow screens. Multi-column and frame-based layouts may require viewport-aware adjustments in the CSS. Test on a phone or use your browser's device emulation mode to check the mobile experience before publishing.

Start with three things. First, verify that the JavaScript file is referenced in the page's head section. Second, confirm that the script file was included in the export output. Third, check that the navigation HTML uses nested list items with the correct class names that the menu script expects. If all three are correct and the menu still does not open, check the browser's developer console for JavaScript errors. The JavaScript menu reference documents the required markup pattern.

This is almost always a hover delay setting that is too short. The menu script includes a configurable delay between the mouse leaving a menu item and the dropdown closing. If that delay is set below 200 milliseconds, most users will experience the menu as flickering or unstable. Increase the hover delay in the menu configuration to 250 or 300 milliseconds. That range feels responsive without causing accidental closures during normal mouse movement.

Yes. The menu script handles keyboard focus management so that visitors using Tab and arrow key navigation can reach every link, including items inside dropdown panels. This is important for accessibility compliance and for users who prefer keyboard-driven browsing. If keyboard navigation is not working, verify that the correct version of the menu script is attached. Older versions may lack full keyboard support.

The menu script expects a specific HTML structure: a navigation list with nested sublists using the class names documented in the JavaScript menu reference. If you replicate that markup structure in a hand-coded page, the script will work. The script itself has no dependency on the DFM2HTML editor. It is a standalone JavaScript file that attaches to conforming HTML.

The most common cause is a file path mismatch between the HTML references and the actual file locations on the server. Check two things: that the image files were uploaded into the correct subfolder matching the exported directory structure, and that the filename case matches exactly. Windows is case-insensitive, but most Linux-based web servers are not. A file named Photo.jpg and photo.jpg are treated as two different files on Linux.

This usually means the link targets were set using absolute file paths from your local machine instead of relative paths. Open the link properties in the editor and verify that each target uses a relative path starting from the page's own location, not a path like C:\Users\YourName\project\page.html. Re-export after correcting and upload the updated files.

The three most common causes are: incorrect file permissions on the server preventing files from being read, case sensitivity differences between your Windows machine and a Linux server, and missing files that were not included in the upload. Check the browser developer console for 404 errors, which tell you exactly which files the server cannot find. Then verify those files exist in the correct locations on the server with the correct filename capitalization.

Browser caching is the most common cause. Your browser stores local copies of previously loaded pages, stylesheets, images, and scripts. When you upload updated files, the browser may continue serving the old cached versions. Press Ctrl+F5 to force a full reload that bypasses the cache. If that does not resolve it, clear the browser cache entirely through the browser settings, or test in a private browsing window which starts with an empty cache.

Some hosting providers and CDN services cache pages at the server level, which means clearing your browser cache alone will not help. Check your hosting control panel for a cache purge or clear cache option. If your host uses Cloudflare or a similar CDN, you can purge individual URLs or the entire cache through their dashboard. Server-side caches typically expire within minutes to hours, so waiting briefly may also resolve the issue.

If you exported with external stylesheets, confirm that the updated CSS file was uploaded along with the updated HTML. A common mistake is uploading only the HTML file and forgetting the associated stylesheet. Also check whether your HTML references a cached version of the CSS by filename. Some advanced setups use versioned filenames or query strings to force cache invalidation. For basic DFM2HTML exports, uploading the complete export folder and doing a hard refresh should resolve CSS caching issues.