document.write() vs. console.log() in JavaScript: What Each One Actually Does

A third-party ad script wipes an entire production page. A defect ticket says “sensitive data was found in the browser console” during a HIPAA audit. Both incidents trace back to the same confusion: treating document.write() and console.log() as interchangeable “print something” commands. The document.write() vs. console.log() distinction is not a syntax detail — one writes content into the live page, the other writes to a debugging channel only developers see, and mixing them up causes two very different categories of production incident. This guide breaks down what each one actually does, where the distinction shows up in real defect tickets, and which one has no place in production code at all.

document.write() vs. console.log(): The Core Difference

Both are built-in JavaScript methods that output something. That’s where the similarity ends. document.write() injects content directly into the HTML document, visible to every user viewing the page. console.log() sends a message to the browser’s developer console, visible only to someone with dev tools open. Confusing which one you’re looking at in a code review is the first mistake; the second is not realizing how differently each one behaves once real network conditions and real users are involved.

How document.write() Actually Behaves

document.write() inserts HTML or text at the exact point in the document where the script executes — but only while the page is still parsing. Call it after the page has finished loading, and the behavior changes completely: instead of inserting content, it erases the entire existing page and replaces it with whatever you just wrote.

// During initial parsing — inserts content normally
document.write("<p>Loading dashboard...</p>");

// After the page has finished loading — wipes everything
window.addEventListener("load", () => {
  document.write("<p>Session expired</p>");
  // The entire page — nav, forms, data — is gone.
  // Only this paragraph remains.
});

This is not a theoretical edge case. It is the single most common way document.write() causes production incidents: a third-party script — an ad tag, an old analytics snippet, an embedded widget — calls it after the page has already rendered, and the page the user was looking at disappears.

Chrome’s own Lighthouse documentation confirms the severity: Google’s official Lighthouse guidance states that document.write() can delay page content by tens of seconds on slow connections, and that Chrome actively blocks its execution in many cases rather than let it run. That means you cannot even rely on the call happening — modern Chrome may silently skip it and log a violation warning instead, which turns “the page got wiped” into “the page silently failed to update,” an even harder defect to trace.

How console.log() Actually Behaves

console.log() sends its argument — a string, number, object, or array — to the browser’s developer console. It has zero effect on the rendered page. A user browsing normally never sees it. This makes it the correct default tool for debugging, but it comes with its own category of risk: anything logged stays visible to anyone who opens dev tools, including in a production environment, unless it’s explicitly stripped out before release.

console.log() is also just one method in a larger console API, and knowing the others changes how efficiently you can read a defect reproduction session.

For anyone reproducing a defect in the browser console, switching from plain console.log() to console.table() on an array of API records, or filtering by console.error only, cuts through noise far faster than scrolling a flat log.

Where This Distinction Matters in QA, BA, and IT Work

Reproducing Defects in the Browser Console

When a tester opens dev tools to reproduce an issue, understanding that console.log() output is safe to trigger repeatedly — while document.write() is not — prevents an exploratory testing session from accidentally destroying the page state you’re trying to inspect.

Legacy Code Audits and Third-Party Script Reviews

Any code audit or vendor security review that flags document.write() usage is not being pedantic — it is flagging a documented, Chrome-verified performance and reliability risk, tied directly to the JavaScript building blocks that make up how a page executes its statements during load. On a legacy system with third-party widgets, this is one of the first things worth checking during a modernization audit.

Compliance Review of Logged Data

In HIPAA- or PCI-adjacent systems, console.log() calls left in production code are a real compliance surface. Anything logged to the console — a patient ID, an account number, a session token — is retrievable by anyone who opens dev tools on that page, and that includes automated scraping tools looking specifically for exposed data.

function renderAppointment(patient) {
  console.log("Rendering appointment for:", patient);
  // ...render logic
}

function renderAppointment(patient) {
  if (process.env.NODE_ENV !== "production") {
    console.log("Rendering appointment for:", patient.id);
  }
  // ...render logic
}

A QA Decision Tree: Is This Output Method Safe?

Which method is called?

console.log()
document.write()

Does it log PII/PHI?
Gate behind env check

Called after page load?
Flag as a defect

Safe for debugging.
Remove or gate before
merging to production.

High-risk pattern.
Replace with DOM methods
(createElement/appendChild).

Common Mistakes

Assuming document.write() is just an old-fashioned console.log(). It is not a debugging tool at all — it was designed to build the page itself during the initial HTML parse. Using it for debugging output is both outdated and, given Chrome’s blocking behavior, unreliable.

Leaving console.log() calls in production builds by default. Most modern build tools (Webpack, Vite, esbuild) can strip console statements automatically in production builds, but only if that step is explicitly configured. Assuming it happens automatically is a common gap QA should verify, not assume.

Trusting document.write() to run at all. Because Chrome may silently block the call on slow connections per its own documented intervention policy, testing only on fast office Wi-Fi can miss this failure mode entirely — exactly what happened in the financial dashboard scenario above.

Logging entire objects instead of specific fields. console.log(user) captures everything on that object, including fields nobody intended to expose. Logging user.id instead of user is a small habit that meaningfully reduces what a leftover log statement can leak.

When I’d Use Each Approach

console.log() and its variants: constantly, during active development and defect reproduction — that’s what it’s for. Strip it before code reaches production, or gate it behind an environment check if some logging needs to persist for support diagnostics.

document.write(): essentially never, in any code written today. If you’re auditing legacy code and find it, treat it as technical debt with a documented, Google-verified performance cost, not a stylistic preference to leave alone.

Quick Reference Checklist by Role

The next time a page “just goes blank” after load, or a security review flags data in the console, check which of these two methods is actually responsible before assuming the defect lives somewhere more complicated. One overwrites what the user sees; the other only leaks what a developer — or an attacker with dev tools open — can find.

Further reading: MDN’s official document.write() reference documents its full behavior and deprecation warnings. For the performance case against it, see Chrome’s official Lighthouse audit documentation.