wxrks Web Preview lets you see a website rendered with your translations as you work, instead of translating blind against a spreadsheet of strings. Because it works by fetching and rendering the live site, a handful of requirements on the website's own side determine whether it will render at all — this article covers those requirements and a few related quirks to expect.
​

💡 Who is this for? Vendors, Project Managers, and Account Admins working on website localization Work Units in the wxrks Editor. Several requirements below are about the target website's own server configuration (CORS, robots/bot rules) rather than a wxrks setting — you may need to share this article with whoever manages that website's hosting or IT.

Open a Work Unit in the Editor and select Web Preview from the preview mode selector in the bottom-left panel — see wxrks Preview: Supported File Extensions for when Web Preview is picked automatically versus when you choose it. Type a URL into the box, the same way you would in a browser's address bar, and click Go. The page loads in the preview panel.
​

Web Preview works on a "best attempt" basis. You don't need to be translating the site's actual HTML to use it — the file can be TXT, JSON, YAML, XLIFF, XML, or anything else, as long as it contains the site's content and you provide the site's URL. As you confirm translated segments, wxrks locates the matching text in the rendered page and replaces it with your confirmed translation.
​

A couple of edge cases to know about: certain characters and line breaks can occasionally prevent a translation from rendering correctly, though this is rare. Web Preview also only translates text that's actually rendered in the page's DOM — strings embedded in CSS or JavaScript won't show as translated in the preview, even if they're part of your source file.

For Web Preview to render a page successfully, the target website needs to meet all three of the following:
​

If your website sits behind basic HTTP authentication, wxrks can be configured to support it. Ask your Account Admin to set this up for the relevant Organizational Unit so Web Preview can authenticate before rendering.
​

Caveat: if images or other assets the page loads live in the same authenticated domain, your browser may still show its own native basic-auth popup when it tries to load them directly. If the initial page request already satisfies the authentication, and the remaining assets are publicly available (for example, served from a CDN), Web Preview renders normally with no further action needed. If you do have the basic HTTP credentials on hand, you can enter them in that browser popup and the preview will load normally as well.

If your website relies on third-party cookies, trackers, or embedded functionality from other domains, rendering can be affected by CORS (Cross-Origin Resource Sharing) rules set by those third-party sites — this is a restriction the third party enforces, not something wxrks or your own site can override from the preview side.

If your website has protections in place to block bots or scrapers, this can prevent Web Preview from rendering the page. wxrks is not a bot or a scraper, but some detection systems flag its automated, programmatic requests as one and block them anyway.

When you bulk-translate all segments in a Work Unit using Machine Translation or Translation Memory, not every segment is necessarily confirmed afterward. If you click Apply Targets to preview the page with your translations, some strings may not appear yet — the Editor paginates segments for performance, so not all of them are loaded into your browser right away. As you confirm segments, or scroll through the Editor to load more, your browser fills in the rest, building toward a complete translated preview.