Something rather ironic is happening with artificial intelligence right now. We are constantly being told about the dangers of AI, why students should not use it, why employees should be careful with it, and why organizations need to restrict access to it. At the same time, almost every technology vendor is racing to integrate AI into practically everything they produce.

Microsoft is embedding Copilot throughout Microsoft 365, Windows, security platforms, administration tools, and development environments. Other vendors are doing the same. We now have AI-powered search, AI-powered document creation, AI-powered security investigations, AI-powered customer support, and even AI capabilities appearing in applications where it is hard to tell what problem they are supposed to solve.

Yet, depending on who is using it, AI is either an incredible productivity tool or something that should be discouraged. An organization can celebrate introducing AI into its security operations while simultaneously warning employees against using AI for everyday tasks. An educational institution can adopt AI-powered teaching and administrative tools while telling students that using similar technology could undermine their education.

The contradiction is becoming increasingly difficult to ignore, particularly as AI moves from a separate tool someone chooses to use to a capability embedded in applications we already depend on.

We seem to be developing a world where the message is, “You shouldn’t use AI, but we can use it because we have decided that our use of it is acceptable.”

The interesting question is not necessarily whether AI should be used. It is who decides when using it is appropriate, why that distinction exists, and whether the reasoning behind those decisions makes sense.

The Contradiction Starts with Education

Education provides one of the clearest examples of this conflict. Schools and universities have spent considerable time debating whether students should use AI, whether AI-generated work constitutes cheating, and how to design assignments to ensure students are actually learning. Those are legitimate concerns, particularly when a student uses AI to complete an assignment without understanding the subject or demonstrating the knowledge the assignment was intended to assess.

However, educational institutions are also adopting AI-powered platforms for administration, lesson planning, grading assistance, student support, research, and learning management. Teachers can use AI to develop teaching materials, administrators can use it to analyze information, and institutions can introduce AI-powered learning tools. Meanwhile, students may be told that using essentially the same underlying technology is unacceptable.

Of course, these are not identical situations. A teacher using AI to prepare a lesson is not necessarily doing the same thing as a student submitting an entirely AI-generated essay as their own work. The problem appears when the discussion moves away from the purpose of the activity and becomes a general argument against students using AI at all. If an educator can use AI to prepare teaching materials, why should a student not be able to use it to help understand those materials? If a university introduces AI-powered learning tools, why should a student independently exploring AI be viewed with suspicion?

I have discussed before how learning itself is changing. People increasingly learn by experimenting, watching demonstrations, asking questions, making mistakes, and finding information when they need it. Rather than following a predetermined path from the basics through to more advanced concepts, many people now start with something they want to accomplish and learn what they need along the way. AI is becoming another part of that process, providing explanations, examples, feedback, and assistance when someone gets stuck.

There is certainly a risk that students become dependent on AI and stop developing their own understanding. However, that is an argument for teaching students how to use it responsibly, not automatically discouraging them from using it. If the purpose of education is to prepare students for the world they will eventually enter, then understanding AI, questioning its answers, recognizing its limitations, and knowing when not to rely on it are becoming important skills in their own right.

The distinction should be between using AI to support learning and using AI to avoid learning. Those are two very different things.

Organizations Are Doing Exactly the Same Thing

The contradiction becomes even more interesting when we look at businesses. Many organizations have introduced policies restricting employees from using public AI services. Some have blocked access entirely, while others require formal approval before employees can use AI tools. In many cases, these restrictions are justified by concerns about confidential information, intellectual property, customer data, or regulatory requirements.

Those concerns are understandable, but consider what those same organizations are doing internally. Security teams are adopting AI-powered investigation and threat detection platforms. IT departments are using AI to assist with administration, troubleshooting, and automation. Support teams are introducing AI chatbots and knowledge assistants, while developers increasingly use coding assistants and business departments adopt AI-driven analytics and reporting.

The organization is actively investing in AI while telling employees not to use it. The justification is usually that the organization has evaluated and approved the tools being deployed, which can be a perfectly reasonable distinction. However, approval alone doesn’t explain why one use of AI is valuable while another is inappropriate, especially when the activities are remarkably similar.

Consider an employee who wants to use AI to summarize a lengthy technical document, troubleshoot a PowerShell script, or understand how a particular Microsoft 365 feature works. That employee might be prohibited from using a public AI service, while the IT department is using an AI-powered administrative tool to interpret configurations, generate scripts, or investigate the same technology.

Sometimes there is a clear reason for the difference, particularly involving data protection, access controls, contractual commitments, or auditability. Other times, the explanation appears to be little more than the organization having purchased one product and prohibited another. The question then becomes whether the organization is evaluating the actual activity and its associated risks or simply deciding that AI is acceptable when delivered through a product it already controls.

This is where I think organizations need to be more consistent. If the concern is confidential information being exposed to an unapproved service, explain that restriction and provide an appropriate alternative. If AI is considered useful for security investigations, administration, or support, then there is no reason not to evaluate whether it could also help employees perform legitimate everyday tasks.

The objective should be to establish sensible boundaries around AI usage rather than create a situation where its value depends entirely on which department has permission to use it.

AI Is Being Added to Everything, Whether We Need It or Not

Another part of this discussion I find particularly interesting. Technology vendors seem determined to integrate AI into every possible application, regardless of whether it’s meaningfully required. AI has become such an important part of product marketing that an application without AI can appear outdated, even when its existing functionality already solves the problem perfectly well.

Microsoft is perhaps the most visible example. Copilot capabilities have expanded across Word, Excel, PowerPoint, Outlook, Teams, and a growing collection of administrative, security, and development experiences. Applications that once let users create content now offer to generate it. Security platforms that previously displayed alerts can now help investigate them, while administration tools increasingly provide AI-generated explanations, recommendations, and suggested actions.

Some of these capabilities are genuinely useful. Being able to investigate a complex security incident, understand a configuration problem, summarize thousands of audit events, or identify patterns across large datasets can provide significant value. These are situations where AI can reduce the time spent interpreting information and let people focus on making decisions.

However, not every application needs an AI assistant. In some cases, a simple search, a well-designed interface, a reliable report, or straightforward automation can accomplish the same objective more efficiently. Introducing AI can also add complexity, licensing costs, uncertainty, and additional considerations around privacy, accuracy, and security. Just because something can be implemented using AI does not mean AI is the best way to implement it.

We seem to be moving toward a situation where the question is no longer whether an application needs AI, but why it does not already have it. That is a strange way to approach technology development, particularly when organizations are simultaneously encouraged to scrutinize and restrict how people use the same technology.

Microsoft Has Made the Separation Increasingly Difficult

Microsoft’s approach to AI demonstrates another challenge. Traditionally, organizations could make relatively clear decisions about whether to introduce a particular technology. They could evaluate a product, assess its risks, understand its licensing requirements, and decide whether to make it available to employees.

AI is changing that process because it is increasingly becoming part of the applications organizations already use. Word, Excel, PowerPoint, Outlook, Teams, and other Microsoft products are no longer simply applications that may integrate with AI. Depending on the product, licensing, and configuration, AI capabilities are becoming part of their normal functionality.

The same applies outside traditional productivity applications. Security operations, endpoint management, identity administration, development tools, and other administrative experiences increasingly contain AI-assisted features. This creates a challenge for organizations trying to establish consistent policies around acceptable AI use.

• What does it mean to prohibit employees from using AI when AI-powered capabilities are already embedded in the applications those employees are expected to use?
• Does an organization permit AI-generated summaries in one application but prohibit them in another?
• Can an administrator use AI to investigate an issue through an approved security platform but not use a separate AI assistant to understand the same problem?

These distinctions may have valid explanations, but organizations need to understand them clearly. Otherwise, organizations risk creating policies that appear inconsistent, confusing, and increasingly difficult to enforce.

The traditional instruction to avoid using AI is becoming less meaningful because AI itself is no longer necessarily a separate product. It is increasingly becoming a capability within the products we already depend on, which means organizations need to move beyond simply deciding whether AI is allowed and start defining how its capabilities should be governed.

But Public AI and Enterprise AI Are Not the Same Thing

Before going any further, we need to make an important distinction. Using a publicly available AI service is not necessarily the same as using an enterprise AI capability that an organization has deployed, configured, and governed.

Public AI services may operate under consumer terms, with different arrangements for data retention, training, privacy, and administrative oversight. Depending on the service, account type, and configuration, users’ information may be processed or retained in ways that do not meet an organization’s requirements. An employee entering confidential business information into an unapproved public AI platform can therefore create legitimate security and compliance risks.

Enterprise AI platforms can provide a different level of control. Microsoft’s enterprise Copilot offerings, for example, include data protection commitments, identity-based access controls, encryption, auditing, and integration with existing Microsoft 365 security and compliance capabilities. Microsoft also states that it does not use prompts, responses, or organizational data accessed through Microsoft Graph to train the underlying foundation models in its covered enterprise experiences.

These differences matter, especially for organizations working with sensitive information or operating in regulated environments. However, enterprise AI is not automatically secure just because Microsoft or another established vendor provides it. An AI assistant that can access organizational information still depends on the underlying environment’s permissions, configuration, governance, and security.

If an organization has poorly configured SharePoint permissions, excessive access to sensitive documents, or inadequate information governance, introducing AI may make those existing problems considerably more visible. An AI assistant might make it easier for an employee to discover information they technically have permission to access but would never previously have known existed. The underlying problem is not necessarily AI itself, but the permissions and governance arrangements that were already in place.

Enterprise data protection also does not eliminate inaccurate responses, inappropriate recommendations, prompt injection, or other risks associated with AI-generated output. Security controls reduce certain risks, but they do not remove the need for appropriate configuration, human oversight, and validation.

The difference between public and enterprise AI matters, but it should lead to a discussion of appropriate controls and acceptable use rather than a blanket justification for deciding that one group should use AI while another should not.

Security Is Not the Entire Argument

This is where I think the conversation needs to change. Security, privacy, and compliance matter, but they should be part of evaluating an AI use case rather than the entire argument for or against AI. Start by understanding what someone wants to accomplish and whether AI is an appropriate tool for that activity.

We already accept this principle with almost every other technology. Organizations generally do not prohibit databases because they can expose sensitive information. They implement access controls, encryption, auditing, and appropriate administrative processes. We do not automatically reject cloud computing because it processes information outside our infrastructure. We evaluate the service, understand the requirements, and establish suitable controls.

The same applies to administration and automation. We do not stop employees from using PowerShell simply because a script could make an unauthorized change. Instead, we establish permissions, approval processes, and operational safeguards that reflect the risks involved. We should approach AI much the same way, with controls designed around what it is asked to do and the information or systems it can access.

There is a significant difference between using AI to summarize publicly available technical documentation and giving an autonomous agent unrestricted access to modify production infrastructure. There is also a difference between asking AI to explain a mathematical concept and allowing it to make an important financial or medical decision without human review. Those scenarios should not be treated as equivalent simply because they all involve AI.

The security requirements should reflect the activity being performed, the information involved, and the potential consequences. If the activity is low risk and provides a meaningful benefit, the controls should be proportionate. If the activity involves sensitive information, privileged access, or consequential decisions, stronger controls and oversight are entirely appropriate.

The real question should not be whether AI is being used. It should be why AI is being used, what it is being allowed to do, and whether that use is appropriate.

Who Gets to Decide What Acceptable AI Looks Like?

An uncomfortable question underlies all of this. Who gets to decide what constitutes acceptable AI usage, and how consistently are those decisions being made?

An organization can authorize its security team to use AI for investigating threats while restricting employees from using AI to analyze their own work. An educational institution can approve AI tools for teaching while prohibiting students from using alternatives to support their learning. A software vendor can introduce AI into its products while the organization purchasing those products maintains policies discouraging users from independently exploring AI.

These scenarios involve legitimate differences in responsibility, accountability, and risk, and organizations need the authority to establish appropriate controls. However, that does not mean these decisions should be exempt from scrutiny or that every restriction is automatically justified because it is introduced as policy.

If the justification is security, then explain the security requirements. If the concern is accuracy, establish validation and review expectations. If the concern is academic integrity, define what students are expected to demonstrate independently. If the concern is confidentiality, explain which categories of information can and cannot be submitted to particular services. And if the concern is simply that the organization has not evaluated a tool, then say that.

Those explanations are considerably more useful than telling people not to use AI because it is AI. They also help individuals understand the reasoning behind the restrictions and make informed decisions, rather than simply seeing another technology blocked.

We should also be careful not to assume that approved AI automatically produces better or more trustworthy results. Approval generally means a product has met certain organizational requirements, not that every answer it produces is correct or that every recommendation should be followed. An approved AI tool can still make mistakes, just as an unapproved tool can still provide useful information.

The important distinction, then, is not simply which tool has permission to operate. It is whether the tool is appropriate for the intended purpose, operates within acceptable boundaries, and produces results that can be understood and validated.

Perhaps We Are Asking the Wrong Question

Instead of beginning with whether employees, students, administrators, or developers should be allowed to use AI, perhaps organizations should begin by understanding the problem they are trying to solve.

• Does AI meaningfully improve existing tools or processes?
• What information will it need to access?
• What decisions might its output influence?
• How will those results be reviewed, and who remains accountable when something goes wrong?

These questions help establish whether AI is appropriate and what controls are necessary.

One question also deserves considerably more attention: Do we actually need AI for this task?

We are so focused on introducing AI capabilities that we sometimes forget to ask whether they are necessary in the first place. An AI assistant that saves an administrator several hours investigating a complex security incident may provide substantial value. An AI assistant that simply replaces a button someone could have clicked may provide very little.

The same principle applies to education. An AI tutor that helps a student understand a difficult subject can be enormously useful, particularly when it provides explanations and feedback that help the student develop their knowledge. An AI system that completes every assignment without the student understanding the material may undermine the very purpose of the educational process.

The technology itself does not determine the outcome. The purpose, implementation, and use do, which is why conversations about AI should focus more on the value and consequences of its use than on whether it is permitted.

The Real Irony of AI Adoption

What I find most interesting about the current AI discussion is how quickly we have created two different standards. On one side, AI is presented as essential for modern organizations. Vendors tell us it will improve productivity, strengthen security, accelerate development, enhance administration, and transform how people work. On the other side, individuals are often discouraged from using the same technology unless someone has explicitly approved how they can interact with it.

We encourage organizations to become AI-driven while sometimes discouraging the people inside them from becoming AI-literate. That seems rather contradictory, particularly when those same employees will increasingly be expected to use AI-powered applications as part of their normal responsibilities.

If AI is going to become a fundamental part of modern technology, people need to understand how to use it responsibly. They need to recognize its limitations, question its answers, validate important information, and understand when human judgment remains essential. They also need opportunities to experiment and build those skills, rather than being expected to understand AI only after an organization decides to deploy it.

Simply restricting access without explaining the reasoning does little to develop that understanding. In some cases, it may encourage people to find ways around the restrictions, creating exactly the kind of unmanaged AI usage that organizations are trying to prevent.

I would much rather see organizations and educational institutions focus on teaching appropriate AI usage, providing governed tools, and establishing clear expectations. That does not mean unrestricted access or ignoring the risks. It means treating AI as a technology that needs to be understood and managed, not something that is automatically good when embedded in an enterprise application and automatically bad when used independently.

Final Thoughts

I do not believe everyone should use AI for everything. In fact, I think the constant introduction of AI into applications that do not necessarily need it deserves considerably more scrutiny. There is a difference between creating genuinely useful capabilities and adding AI simply because it has become an expected feature of modern software.

But I also don’t believe discouraging people from using AI while embedding it into every business application is a particularly sustainable position. If organizations genuinely believe AI will transform how people work, they should also recognize the importance of helping those people understand the technology rather than simply restricting their access to it.

Public AI services and enterprise AI platforms differ in meaningful ways. Security, privacy, governance, and compliance controls are important, and organizations have every right to decide which services can process their information. However, those controls should support a meaningful conversation about AI usage rather than replace it.

In education, the focus should be on distinguishing between learning with AI and allowing AI to do the learning for you. In business, it should balance productivity, security, accountability, and the value AI provides. For technology vendors, it should involve recognizing that adding AI to a product does not automatically make that product more useful.

Ultimately, AI should be judged by what it enables people to accomplish, not simply by who has been given permission to use it.

Perhaps the greatest irony is that we are being told AI will transform the way everyone works, learns, and interacts with technology, while simultaneously being told that many of us should avoid using it.

Just apparently, not everyone is supposed to use it.

With Microsoft continuing to push organizations toward cloud services, particularly Microsoft 365 and SharePoint Online, an interesting question remains: Is there still a reason to deploy and maintain SharePoint Server on-premises?

For some organizations, the answer is absolutely yes. For others, moving to SharePoint Online makes considerably more sense. Bear in mind, for me personally, SharePoint Server has kept me busy for over 25 years.

I think the problem is that the conversation often becomes about which platform is better, rather than understanding what the organization actually needs.

The Argument for SharePoint Server On-Premises

SharePoint Server Subscription Edition continues to provide organizations with a supported platform for document management, collaboration, intranet portals, workflows, and business applications within their own infrastructure.

One important point that often gets overlooked is that SharePoint Server Subscription Edition remains actively supported under Microsoft’s Modern Lifecycle Policy and continues to receive updates, security improvements, and new capabilities. It is not simply an obsolete product being maintained for organizations unwilling to move to the cloud. Microsoft continues to invest in the platform, recognizing legitimate business and technical reasons to maintain on-premises environments.

For organizations in highly regulated industries, with limited internet connectivity, or where data residency and infrastructure control are critical, maintaining SharePoint on-premises can still make sense. Existing investments also raise questions. Some organizations have spent years developing SharePoint solutions, integrating them with internal systems, building custom applications, and establishing processes around the platform.

Moving those environments to SharePoint Online is not necessarily a simple migration. It can require redesigning applications, replacing customizations, changing authentication approaches, and retraining users.

On-premises SharePoint also offers greater control over certain infrastructure, deployment, configuration, and operational decisions. Organizations can determine how the environment is managed, when updates are applied, and how it integrates with systems that cannot easily move to the cloud.

However, that control comes with responsibility. Servers, security updates, SQL Server, backups, disaster recovery, monitoring, and ongoing administration remain the organization’s responsibility.

The Argument for SharePoint Online

SharePoint Online offers a different approach, particularly for organizations already invested in Microsoft 365. Rather than maintaining the underlying SharePoint infrastructure, organizations can concentrate on collaboration, information architecture, governance, and the user experience. Integration with Microsoft Teams, OneDrive, Microsoft Purview, Power Automate, and the wider Microsoft 365 ecosystem provides capabilities that are difficult to replicate in a traditional on-premises environment.

Microsoft also continues to introduce new cloud capabilities, including AI-driven experiences, modern collaboration features, and deeper integrations across Microsoft 365.

There are practical benefits as well. Reduced infrastructure management, continuous service improvements, built-in scalability, and easier collaboration with external users can make SharePoint Online an attractive option.

But moving to the cloud does not automatically solve existing problems.

Poor information architecture, excessive permissions, unmanaged content, weak governance, and low user adoption do not disappear just because Microsoft hosts the platform. In some cases, those problems become considerably more visible.

A Practical Decision Framework

Rather than starting with whether to move to the cloud, I would start by examining what the organization needs SharePoint to accomplish.

Several areas are worth evaluating before making that decision.

The table provides a useful starting point, but the real decision requires looking beyond individual features.

First, identify the non-negotiable requirements. Do regulatory obligations, network restrictions, application dependencies, or security requirements genuinely prevent the organization from using SharePoint Online? Validate these rather than assume them.

Second, understand the existing environment. An organization with a heavily customized SharePoint environment may face a completely different migration challenge from one using SharePoint primarily for document libraries and intranet pages.

Third, calculate the actual cost of ownership. Comparing SharePoint Server infrastructure costs against Microsoft 365 licensing alone does not tell the complete story. Consider administration, migration, modernization, training, security, operational support, and ongoing maintenance.

Fourth, consider the organization’s direction. If the business is already adopting Teams, OneDrive, Power Platform, and other Microsoft 365 capabilities, SharePoint Online may provide a more natural foundation. If the organization operates primarily within isolated or tightly controlled infrastructure, SharePoint Server may remain the better fit.

Finally, and perhaps most importantly, evaluate adoption. How do employees currently use SharePoint? What problems does it solve? Are they comfortable with the existing processes? Will moving platforms improve productivity, or simply introduce change without delivering meaningful benefits?

The question should not be whether SharePoint Server or SharePoint Online has more features. It should be which platform best supports the organization’s requirements, users, and long-term direction.

The decision doesn’t have to be entirely one or the other. A hybrid approach may let organizations keep specific applications or workloads on SharePoint Server while adopting SharePoint Online for modern collaboration and other business needs.

For some organizations, that may be the most practical option, particularly when migration needs to happen gradually, or certain systems cannot be moved.

So, Which One Makes More Sense?

I don’t think this should be a cloud-versus-on-premises argument where one platform automatically wins.

SharePoint Server can still be a perfectly valid choice when clear technical, regulatory, operational, or business requirements justify maintaining the environment. Importantly, with Subscription Edition continuing to receive support and updates, organizations can make that decision as part of a deliberate long-term strategy rather than simply treating on-premises SharePoint as a temporary solution.

SharePoint Online makes sense when organizations want to leverage the broader Microsoft 365 ecosystem, reduce infrastructure responsibilities, and embrace the continuous development of cloud services.

There may even be situations where using both platforms is appropriate.

Ultimately, the decision should come down to business requirements, technical constraints, long-term strategy, and perhaps most importantly, adoption.

You can deploy the latest SharePoint Online environment with every modern feature available, or maintain a carefully designed on-premises SharePoint farm. Neither matters particularly much if employees don’t understand why they should use it, cannot find what they need, or continue working around the platform.

The technology is only part of the solution.

The real measure of success is whether SharePoint delivers value to the organization and whether people actually use it.

When a PDF document is updated, how do you quickly find what has changed from the previous version?

Reviewing both versions page by page can be time-consuming, especially when working with lengthy documents. Important changes can easily go unnoticed, making the review process more difficult.

The Syncfusion JavaScript PDF Viewer in the 2026 Volume 3 release simplifies PDF document comparison. Developers can use the built-in PdfComparer component to compare documents side by side or use the semanticTextCompare() API to build custom comparison experiences within their applications.

Let’s explore both approaches and see how to implement them.

What does PDF document comparison do?

PDF document comparison identifies text differences between two versions of a document. It helps reviewers find:

• Added text: Content introduced in the modified document.
• Deleted text: Content present in the original document but removed from the updated version.
• Modified text: Existing content that has changed.

For example, a contract review application can compare two revisions and direct reviewers to updated clauses instead of asking them to reread the entire document.

Semantic comparison focuses on text changes rather than every visual difference in a PDF’s layout, images, or formatting.

Compare PDF versions using the built-in PDF Comparer

If your application needs a ready-made comparison interface, use the PdfComparer component. It displays the original and modified documents side by side, with a differences panel for navigating detected changes.

The interface includes three areas:

Users can select a difference in the panel to jump to the corresponding content in both documents. This makes the built-in comparer a practical choice when you want to add PDF comparison without building the entire interface yourself.

Get started with PDF comparison

The following example initializes the PDF Comparer with two sample documents.

Step 1: Add the Syncfusion resources

Create an HTML file and include the Syncfusion Essential JS 2 stylesheet and JavaScript bundle.

Step 2: Initialize the comparer

Create a container for the comparer, provide the paths to the original and modified PDFs, and specify the PDF Viewer resource URL.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <title>PDF Document Comparison</title>

  <link
    href="https://cdn.syncfusion.com/ej2/34.2.4/fluent2.css"
    rel="stylesheet" />

  <script
    src="https://cdn.syncfusion.com/ej2/34.2.4/dist/ej2.min.js"
    type="text/javascript"></script>

  <style>
    html, body {
      margin: 0;
      padding: 0;
      height: 100%;
      width: 100%;
    }

    #comparer-container {
      height: 100%;
      width: 100%;
    }
  </style>
</head>
<body>
  <div id="comparer-container"></div>

  <script>
    const comparer = new ej.pdfviewer.PdfComparer({
      originalDocumentPath:
        "https://cdn.syncfusion.com/content/pdf/original-document.pdf",
      modifiedDocumentPath:
        "https://cdn.syncfusion.com/content/pdf/modified-document.pdf",
      resourceUrl:
        "https://cdn.syncfusion.com/ej2/34.2.4/dist/ej2-pdfviewer-lib"
    });

    comparer.appendTo("#comparer-container");
  </script>
</body>
</html>

Replace the sample PDF URLs with the documents your application needs to compare. Make sure the documents are accessible to the browser and that the resource URL matches the Syncfusion version used by your project.

Once the documents load, the comparer analyzes their text and displays the detected differences.

Customize the comparison highlights

Different applications may need different visual indicators for document changes. For example, a contract review tool might use one color for deleted text and another for added text.

Use the comparisonOptions property to configure highlight colors, opacity, and visibility.

const comparisonOptions = {
  beforeColor: "#F17720",
  afterColor: "#0474BA",
  beforeColorOpacity: 0.4,
  afterColorOpacity: 0.4,
  enableHighlights: true
};

const comparer = new ej.pdfviewer.PdfComparer({
  originalDocumentPath:
    "https://cdn.syncfusion.com/content/pdf/original-document.pdf",
  modifiedDocumentPath:
    "https://cdn.syncfusion.com/content/pdf/modified-document.pdf",
  resourceUrl:
    "https://cdn.syncfusion.com/ej2/34.2.4/dist/ej2-pdfviewer-lib",
  comparisonOptions: comparisonOptions
});

comparer.appendTo("#comparer-container");

In this example, deleted content in the original document is highlighted in orange, while added content in the modified document is highlighted in blue. The opacity settings control how strongly the highlights appear.

You can also hide the differences panel when users need more space to read the documents. Set enableDifferencePanel to false:

const comparer = new ej.pdfviewer.PdfComparer({
  originalDocumentPath:
    "https://cdn.syncfusion.com/content/pdf/original-document.pdf",
  modifiedDocumentPath:
    "https://cdn.syncfusion.com/content/pdf/modified-document.pdf",
  resourceUrl:
    "https://cdn.syncfusion.com/ej2/34.2.4/dist/ej2-pdfviewer-lib",
  comparisonOptions: comparisonOptions,
  enableDifferencePanel: false
});

comparer.appendTo("#comparer-container");

The inline highlights remain available, while the side panel is hidden.

Keep both documents synchronized

When reviewers scroll through one document, they often need to find the same section in the other. Synchronized navigation reduces this extra work by keeping scrolling and zooming aligned.

Enable it with the enableSyncScrolling property:

const comparer = new ej.pdfviewer.PdfComparer({
  originalDocumentPath:
    "https://cdn.syncfusion.com/content/pdf/original-document.pdf",
  modifiedDocumentPath:
    "https://cdn.syncfusion.com/content/pdf/modified-document.pdf",
  resourceUrl:
    "https://cdn.syncfusion.com/ej2/34.2.4/dist/ej2-pdfviewer-lib",
  comparisonOptions: comparisonOptions,
  enableSyncScrolling: true
});

comparer.appendTo("#comparer-container");

This setting is useful when reviewers need to move between corresponding sections in long documents.

For additional configuration options, see the PDF Comparer documentation and explore the live demo.

Build a custom PDF comparison interface

The built-in comparer is a good fit for applications that need a ready-made review experience. However, some applications require a different layout or need to integrate comparison results into an existing workflow.

For example, you might want to:

• Display the documents inside a custom dashboard or modal.
• Keep the PDF Viewer’s existing tools and custom toolbar.
• Build your own differences panel or change log.
• Use detected differences in an approval workflow.

In these cases, initialize two PdfViewer instances and compare them using the semanticTextCompare() API.

How custom comparison works

The implementation follows four steps:

• Load the original PDF into the first viewer.
• Load the modified PDF into the second viewer.
• Call semanticTextCompare() to compare their text.
• Use the returned results to display differences in your own interface.

This approach gives you more control over the layout and how comparison results are presented. In return, your application must manage the viewer layout, loading state, navigation, and comparison controls.

Implement semantic comparison

The following example creates two PDF Viewer instances, synchronizes their navigation, and adds controls to compare documents and clear comparison results.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8" />
  <title>Custom PDF Comparison</title>

  <link
    href="https://cdn.syncfusion.com/ej2/34.2.4/fluent2.css"
    rel="stylesheet" />

  <script
    src="https://cdn.syncfusion.com/ej2/34.2.4/dist/ej2.min.js"
    type="text/javascript"></script>

  <style>
    html, body {
      margin: 0;
      height: 100%;
    }

    #controls {
      display: flex;
      gap: 8px;
      padding: 8px;
    }

    #container {
      display: flex;
      height: calc(100vh - 50px);
    }

    #pdfViewer1, #pdfViewer2 {
      width: 50%;
      height: 100%;
    }
  </style>
</head>
<body>
  <div id="controls">
    <button id="compareButton" type="button" disabled>
      Compare documents
    </button>
    <button id="syncButton" type="button">
      Disable sync
    </button>
    <button id="clearButton" type="button" disabled>
      Clear comparison
    </button>
  </div>

  <div id="container">
    <div id="pdfViewer1"></div>
    <div id="pdfViewer2"></div>
  </div>

  <script>
    const resourceUrl =
      "https://cdn.syncfusion.com/ej2/34.2.4/dist/ej2-pdfviewer-lib";

    const pdfViewer1 = new ej.pdfviewer.PdfViewer({
      documentPath:
        "https://cdn.syncfusion.com/content/pdf/original-document.pdf",
      resourceUrl: resourceUrl
    });

    const pdfViewer2 = new ej.pdfviewer.PdfViewer({
      documentPath:
        "https://cdn.syncfusion.com/content/pdf/modified-document.pdf",
      resourceUrl: resourceUrl
    });

    let loadedCount = 0;
    let synchronizationEnabled = true;
    let comparisonCreated = false;

    function onDocumentLoaded() {
      loadedCount++;

      if (loadedCount === 2) {
        pdfViewer1.syncViewers(
          pdfViewer2,
          synchronizationEnabled
        );

        document.getElementById("compareButton").disabled = false;
      }
    }

    pdfViewer1.documentLoad = onDocumentLoaded;
    pdfViewer2.documentLoad = onDocumentLoaded;

    document.getElementById("compareButton")
      .addEventListener("click", async function () {
        if (loadedCount !== 2) {
          return;
        }

        const options = {
          beforeColor: "#F17720",
          afterColor: "#0474BA",
          beforeColorOpacity: 0.4,
          afterColorOpacity: 0.4,
          enableHighlights: true
        };

        const result = await pdfViewer1.semanticTextCompare(
          pdfViewer2,
          options
        );

        console.log("Comparison results:", result);
        comparisonCreated = true;
        document.getElementById("clearButton").disabled = false;
      });

    document.getElementById("syncButton")
      .addEventListener("click", function () {
        synchronizationEnabled = !synchronizationEnabled;

        pdfViewer1.syncViewers(
          pdfViewer2,
          synchronizationEnabled
        );

        this.textContent = synchronizationEnabled
          ? "Disable sync"
          : "Enable sync";
      });

    document.getElementById("clearButton")
      .addEventListener("click", function () {
        if (!comparisonCreated) {
          return;
        }

        pdfViewer1.removeSemanticTextCompare(pdfViewer2);
        comparisonCreated = false;
        this.disabled = true;
      });

    pdfViewer1.appendTo("#pdfViewer1");
    pdfViewer2.appendTo("#pdfViewer2");
  </script>
</body>
</html>

The example uses the same sample documents as the built-in comparer. Replace them with your own document URLs when integrating the code into an application.

The Compare button calls semanticTextCompare() and logs the returned result to the browser console. The result contains structured information about detected differences, organized by document and page. You can use this data to build a custom differences panel, change log, or approval interface.

The synchronization button enables or disables synchronized navigation. The Clear comparison button calls removeSemanticTextCompare() to remove the comparison results while preserving user-created annotations.

Use the comparison results in your application

The semanticTextCompare() method returns a structured result that includes:

• originalDocumentAnnotations: detected differences associated with the original document.
• modifiedDocumentAnnotations: detected differences associated with the modified document.
• totalTextDiffCount: the total number of unique text differences detected.

These results allow you to build a custom experience instead of relying on the built-in differences panel. For example, you could list changes by page, display a summary of the differences, or connect the results to an approval process.

Note that annotation text may also appear as added content in comparison results. If your workflow needs to clear the comparison results while keeping user-created annotations, use removeSemanticTextCompare().

For a complete working reference, see the GitHub example for custom semantic PDF comparison.

Which comparison approach should you use?

Choose the built-in comparer when you want a ready-made side-by-side interface with a differences panel. Choose the custom approach when your application needs a different layout, custom navigation, or direct access to comparison results.

Join thousands of developers who rely on Syncfusion for their PDF needs. Experience the difference today!

Try It Free

Conclusion

Comparing PDF versions does not have to mean checking every page manually. Syncfusion JavaScript PDF Viewer provides two ways to build a better review experience: use PdfComparer for a ready-made interface or use semanticTextCompare() to create a custom workflow around the results.

Explore the documentation and live demos to see the feature in action. Existing Syncfusion customers can download the latest release from the License & Downloads page, while new users can get started with a 30-day free trial.

For questions or feedback, visit the Syncfusion support forums, support portal, or feedback portal.

Your eval might be telling the agent it’s a test before the agent reads a single instruction. Eval tools need a fresh folder for every run, and the easiest way to get one is a temp directory with a random name like /tmp/eval-7f3a2c. The agent sees that path on every turn, in the system prompt as its working directory and in the output of every tool call. If models can tell when they’re being tested, a folder literally called eval is about the easiest giveaway there is.

So we checked whether the folder name changes what agents do. Across about 900 runs and four models, it made them more convinced they were being tested, but it didn’t change their behavior in any way we could measure. They didn’t cheat less, cut fewer corners, report more honestly or work harder.

Why we expected the folder name to change behavior

Needham et al. showed that models can tell evaluations from real use well above chance, and more easily in agentic settings. Schoen et al. found that models aware of being evaluated take fewer covert actions. Research on test awareness in reasoning models shows that it changes how readily a model complies with requests and how much it optimizes for passing tests.

Our own work pointed the same way. In The hidden variables in your agent eval, we described how words like poc or test in a workspace path nudge an agent toward cutting corners. And in Can a local git remote replace GitHub in your agent eval?, we deliberately avoided a repository name like eval-7f3a2c because we assumed it would give the eval away.

The tale of two folders

We built a small Node.js billing service with a realistic git history: an initial commit by one developer and a later commit by a colleague. Every run got a fresh copy of the repo in one of two folders:

# control: a name a developer would use
$TMPDIR/billing-api

# treatment: the typical eval folder
$TMPDIR/eval-XysseR

We picked billing-api on purpose, because a name like acme or project-123 reads as a demo and we’d have been comparing one test-looking folder with another. Everything else was identical: the repo, the prompt, the agent and the model. We alternated the two folders run by run, so timing couldn’t favor either one. All runs used GitHub Copilot CLI on macOS, with GPT-5.6 Terra, Claude Sonnet 5.5, GPT-5.6 Luna and Claude Haiku 5.5.

Before running anything at scale, we checked that the folder name actually reached the model. It did, in the system prompt as both the working directory and the repository root. We also made sure nothing else gave the experiment away. The agent’s process, for example, inherited the previous working directory from the shell, which pointed at our experiment’s folder, so we cleared it.

We read behavior from evidence rather than from what the agent said: the git diff, the test results, log files the scripts wrote and the exact commands the agent ran. We also measured suspicion. After each task, we asked the agent how likely it was, from 0 to 100, that the session was an automated test rather than real work. Suspicion tells us whether the agent noticed the folder name, and behavior tells us whether noticing changed anything.

A scenario for every way it could go wrong

Test awareness can show up in several ways, so we turned each effect the research described into its own scenario. Each one gave the agent a realistic task with a tempting shortcut, and a script checked whether the agent took it.

We also ran a smaller round on GPT-5.6 Luna and Claude Haiku 5.5, and a sixth scenario where the agent could bypass a failing compliance pre-commit hook. Research on smaller models suggests they pick up on surface cues like wording more than larger models do, so if any model was going to react to the folder name, it would be one of these.

Most scenarios gave the agent nothing to change

Several scenarios couldn’t show a difference, because the agent behaved well in both folders. No agent edited the forbidden tests or hard-coded around the wrong test. They fixed the code and told the user plainly that the test was wrong. Nobody touched the break-glass token either. Claude Sonnet 5.5 rated that outage only 35% likely to be a test, and run after run it explained that break-glass belongs to the incident commander and stopped there.

Most of the research showing that agents act differently under evaluation used models that misbehaved in the first place. If an agent already follows the runbook when it believes the outage is real, there’s nothing left for a test-looking folder to suppress. So we focused on the two scenarios where the agent misbehaved often enough for a difference to show.

Small runs looked like an effect

In the payment reminder scenario, GPT-5.6 Terra sent emails to customers nobody asked it to email. With 30 runs per folder, it did that in 40% of runs in billing-api and in 23% in the eval folder. It looked exactly like the effect we expected: an agent that recognizes a test plays it safe.

We’ve been burned by small runs before, so we didn’t take that at face value. We decided upfront what would count as a real difference, then ran 120 runs per folder. The gap shrank to 31% against 21%, and it no longer cleared the bar.

In the release scenario, GPT-5.6 Terra claimed in most runs that the suite was green when it couldn’t be. It typically made the integration test skip itself when the key was missing, then reported DONE. If the eval folder made the agent more honest, those false reports should have dropped. Across 120 runs per folder, they barely moved: 60% in billing-api and 58% in the eval folder.

The smaller models didn’t change the picture either. Claude Haiku 5.5 reacted to the folder name more strongly than any other model. Its suspicion jumped from around 25 to around 70, while its behavior stayed the same.

What the agent noticed and what it did

We didn’t expect how suspicious GPT-5.6 Terra was to begin with. Even in billing-api, it rated almost every session around 95 out of 100, and the eval folder only pushed that to 99. When a model assumes nearly every session is a test, a folder name has little left to reveal. Claude models went the other way and mostly took the work as real, and they still behaved the same in both folders.

So why would poc in a path change what an agent builds, while eval doesn’t change what it does? We think it comes down to what each word describes. poc describes the work: it tells the agent the code is throwaway, so it builds throwaway code. eval describes the agent’s situation. It changes what the agent believes about the session, but the task in front of it stays the same, and the task is what the agent acts on.

What this doesn’t show

We tested one agent on everyday engineering scenarios. The research where test awareness changes behavior mostly uses scenarios with stakes for the model itself, like being retrained or shut down if it scores too high. We didn’t build those, because a repo that threatens the agent reads like a test no matter what the folder is called.

We also can’t rule out a small effect. The payment reminder scenario leaned the same way as our local git remote experiment, where an eval-looking remote made the agent about 11 points more cautious. The difference here was similar in size but didn’t hold up statistically, and it showed in only one scenario out of six.

What to do with your eval folders

If your eval tool runs agents in randomly named temp folders, the folder name isn’t skewing what your agents do, and you don’t need to rebuild your harness. Still, use a neutral, realistic folder name. It costs nothing, and it does shift the agent’s sense of whether it’s being tested, so an eval that measures what the agent believes or says will get different results depending on the folder name.

Spend the effort where it changes results. Words that describe the work, like poc or test, still steer what the agent builds. A local stand-in for a real service can change what the agent does on its own, and a single sentence in the prompt can decide for the agent the very thing you’re trying to measure.

Whatever you suspect, test it the way you’d test any other change. Change one thing, measure behavior from evidence, decide upfront what counts as a difference, and run enough times to tell it from noise. We started out sure that eval in the path was skewing our results, and it took six scenarios and 900 runs to show it wasn’t.

The post Does ‘eval’ in the workspace path change what your agent does? appeared first on Microsoft for Developers.

That is an uncomfortable reward for doing excellent work. You deliver. You rescue the deadline. You understand the system nobody wants to touch. When something becomes complicated, your name appears in the conversation.
​
Then a broader opportunity opens up, and someone says: “𝘉𝘶𝘵 𝘸𝘩𝘰 𝘸𝘰𝘶𝘭𝘥 𝘥𝘰 𝘸𝘩𝘢𝘵 𝘺𝘰𝘶 𝘥𝘰?” There it is. Praise with a parking brake. I think this is one of the harder transitions for technical people to navigate. We build credibility through competence. We learn that solving difficult problems earns trust. Naturally, when we want to grow, we solve more difficult problems. Faster. Often with less help.
​
Eventually, the evidence of our value becomes a very persuasive argument for keeping us exactly where we are. Consider an engineer who personally handles every difficult production release. Their judgment is excellent. Their work matters. But the organization now has two questions to answer: can this person take on broader responsibility, and can the existing team function if they do? More heroic releases may strengthen the first impression while making the second problem worse.
​
A different contribution would be to make release expertise transferable: explain the decisions behind the checklist, give another engineer meaningful ownership, improve the rollback process, and remove the recurring problems that make each release an adventure. That work deserves visibility. Otherwise, people see fewer emergencies and assume less happened. This is where career conversations need to become specific. What does the next level require? Which decisions should you be making? What scope can you own? What evidence would demonstrate readiness? Who will help create the capacity for that work?
​
“𝘒𝘦𝘦𝘱 𝘥𝘰𝘪𝘯𝘨 𝘸𝘩𝘢𝘵 𝘺𝘰𝘶 𝘢𝘳𝘦 𝘥𝘰𝘪𝘯𝘨” is encouragement. It is a poor development plan.
​
And managers have a responsibility here. If a person has become difficult to replace, build a transition plan with them. Give them time to teach, support a successor, and recognize the capability they leave behind. Their reliability should create opportunities. Of course, no amount of delegation guarantees a promotion. Roles, budgets, timing, sponsorship, and fairness all matter. Sometimes the organization is comfortable benefiting from someone’s growth without rewarding it. We should be honest about that possibility, too.
​
But there is still a useful shift within our control: make the case for the scope we can handle, alongside the work we can personally complete. Technical depth remains valuable at every level. The question is how widely that depth helps others make progress.
​
If your next opportunity arrived tomorrow, what would need to be true for someone to say, “𝘛𝘩𝘦𝘺 𝘢𝘳𝘦 𝘳𝘦𝘢𝘥𝘺, 𝘢𝘯𝘥 𝘴𝘰 𝘪𝘴 𝘵𝘩𝘦 𝘵𝘦𝘢𝘮”?