Support for "Whole Word Only" matching in PDF FindText method

[Jackson Tong]

I am currently using the Syncfusion PDF .NET library to implement text search functionality within PDFs. While the FindText method works great for standard searches, I have run into a limitation where it lacks support for Whole Word matching.

Currently, FindText returns partial matches/substrings, which can cause accuracy issues depending on the data we are parsing.

Example Scenario:

• PDF Content: A document contains the numeric string 1,100.00.

• Search Query: 100 with the intended constraint of finding only the exact whole word/number "100".

• Current Behavior: FindText matches the "100" inside 1,100.00.

• Expected Behavior (with Whole Word enabled): It should not match, as "100" is part of a larger token (1,100.00).

References:

Other major PDF SDKs natively support this capability as a standard parameter or flag in their search APIs. For example:

• Apryse: Includes a dedicated whole-word text search flag, as documented here: Apryse Text Search Documentation.

• Nutrient: Explictly includes a matchWholeWord boolean parameter in their text searching method, as documented here: Nutrient GdPicture PDF SearchText API.

[Jeyalakshmi Thangamarippandian]

Hi Jackson Tong,

yes, the PDF library provides support for whole‑word text search options. In the FindText method, you can use the appropriate text search options overload to enable whole‑word searching.

Code:

TextSearchOptions searchOption =  TextSearchOptions.WholeWords;
TextSearchResultCollection results;
loadedDocument.FindText(new List<string> { "100" }, searchOption, out results);
 

Please refer to the following UG link for more details.

Working with Text Extraction | Syncfusion

Regards,

Jeyalakshmi T

[Jackson Tong]

Hi Jeyalakshmi,

It's not working, on my example code it's still able to search for 748,000 which is part of 6,748,000

Attachment: syncfusiondemo_21406809.zip

[Jeyalakshmi Thangamarippandian]

Hi Jackson Tong,

We were able to reproduce the reported issue with the provided details on our end and currently we are analyzing on this and will update the further details by July 6th, 2026.

Regards,

Jeyalakshmi T

[Jeyalakshmi Thangamarippandian]

Hi Jackson Tong, 

We confirmed the issue "TextSearchOptions.WholeWords Incorrectly Matches Partial Numeric Text Within a Larger Word" as a defect in our product and we will include the fix into our upcoming weekly NuGet release, which will be available on July 14, 2026.

Please use the feedback link below to track the status of the reported bug.

TextSearchOptions.WholeWords Incorrectly Matches Partial Numeric Text Within a Larger Word in ASP.N…

Disclaimer: “Inclusion of this solution in the weekly release may change due to other factors including but not limited to QA checks and works reprioritization.”

Regards,

Jeyalakshmi T

[Jeyalakshmi Thangamarippandian]

Hi Jackson Tong, 

We have included the fix for the reported issue where "TextSearchOptions.WholeWords Incorrectly Matches Partial Numeric Text Within a Larger Word" in our latest weekly NuGet release (v34.1.31).

Please use the below link to download our latest weekly NuGet:

NuGet Gallery | Syncfusion.Pdf.Net.Core 34.1.31

Cause:

The issue occurs due to a limitation in the whole-word boundary validation, where numeric values containing separators are not evaluated correctly. This can lead to unintended text matches and result in the reported behavior.

Regards,

Jeyalakshmi T

[Jackson Tong]

Hi Jeyalakshmi,

Thanks for the release, I find that if the search term is in the middle of the text the it's unable to find the term (expected), eg: search term 748,000 which is part of 6,748,000. However if the number contains decimals then it still be able to find the term, eg: search tem: 899.50 which is part of 11,029,899.50

Attachment: dummy_financial_report.pdf_2007dbca.zip

[Jeyalakshmi Thangamarippandian]

Hi Jackson Tong,

Since this is a new document and the scenario appears to be different, we consider this a new issue.

 

We confirmed the issue "TextSearchOptions.WholeWords Incorrectly Identifies Partial Numeric Text as Whole Words in Decimal Numbers" as a defect in our product and we will include the fix into our upcoming weekly NuGet release, which will be available on July 28, 2026.

 

Please use the below feedback link to track the status of the reported bug.

TextSearchOptions.WholeWords Incorrectly Identifies Partial Numeric Text as Whole Words in Decimal …

 

Disclaimer: “Inclusion of this solution in the weekly release may change due to other factors including but not limited to QA checks and works reprioritization.” 

Regards,

Jeyalakshmi T

[Savithiri Ranganathan]

Hi Jackson Tong,

We apologize for any inconvenience caused. To ensure stability and avoid impacting existing behavior, we were unable to include this fix in this week's release. The fix is now scheduled for the upcoming weekly release on August 04, 2026.

Thank you for your patience and understanding.

Regards,

Savithiri R.

[Savithiri Ranganathan]

Hi Jackson Tong,

We would like to inform you that the Service Pack (SP) release scheduled for today has been postponed to tomorrow due to a minor delay.

We apologize for any inconvenience caused and appreciate your understanding.

 

Regards,

Savithiri R.

[Jeyalakshmi Thangamarippandian]

Hi Jackson Tong,

We are glad to announce that our Essential Studio® 2026 Volume 2 SP Release v34.2.2 is rolled out and is available for download under the following link.

Essential Studio® 2026 Volume 2... | Announcements Forums | Syncfusion

 

We have included the fix for the reported issue where " TextSearchOptions.WholeWords Incorrectly Identifies Partial Numeric Text as Whole Words in Decimal Numbers" in our latest SP release (v34.2.2)

 

Cause:

The issue is caused by a limitation in the text matching logic under certain data formats and patterns. As a result, some text may be matched unexpectedly, leading to the observed behavior.

 

We thank you for your support and appreciate your patience in waiting for this release. Please get in touch with us if you require any further assistance.

Regards,

Jeyalakshmi T

[Donovan Craig]

It's unable to find decimal number, decimal number on PDF 11,029,899.50

• Unable to partial term 899.50 - Good
  
• Unable to find whole number 11,029,899.50 This is still working on older version 34.1.31

Whole number works as expected, whole number on PDF 6,748,000

• Unable to find partial search term 748,000
• Able to find whole number 6,748,000
  

[Jeyalakshmi Thangamarippandian]

Hi Donovan Craig,

We apologize for the inconvenience caused. 

We confirmed the issue "TextSearchOptions.WholeWords Does not work for whole Numeric Text as Whole Words with Decimal Numbers " as a defect in our product and we will include the fix into our upcoming weekly NuGet release, which will be available on August 18, 2026.

 

Please use the below feedback link to track the status of the reported bug.

TextSearchOptions.WholeWords Does not work for whole Numeric Text as Whole Words with Decimal Numbe…

 

Disclaimer: “Inclusion of this solution in the weekly release may change due to other factors including but not limited to QA checks and works reprioritization.”

Regards,

Jeyalakshmi T

[Savithiri Ranganathan]

Hi Donovan Craig,

As promised earlier, we have included the Fix for the reported issue where " TextSearchOptions.WholeWords Does not work for whole Numeric Text as Whole Words with Decimal Numbers " in our latest weekly NuGet release (V34.2.4)

 

Please use the below link to download our latest weekly NuGet:

NuGet Gallery | Syncfusion.Pdf.Net.Core 34.2.4

 

Cause:

The text was rendered using the td operator with additional spacing applied. As a result, the subsequent word began with the displaced numeric characters, causing the text extraction process to fail to recognize it as a complete word.

 

We sincerely thank you for your support and patience as we prepared this release. Please feel free to contact us if you need any further assistance.

 

Regards,

Savithiri R.