Define the extraction result first
This workflow is for people who need a checkable set of signals from raw text, HTML, Markdown, or logs. Before opening a tool, preserve the source and write the expected fields, output shape, duplicate policy, and the context a reviewer will need. A small positive and negative fixture is more useful than a vague instruction to extract everything.
Start broad, then respect the source format
Use text-extractor for a first pass when the fields are not yet settled. If the task is already a known URL collection, bulk-url-extractor gives the task a narrower boundary. Do not flatten HTML before deciding whether attributes or image sources are part of the result: use html-attribute-extractor or image-source-extractor first, then create clean reading text with new-html-tag-stripper if that derivative is needed. Markdown links deserve markdown-link-extractor because link syntax carries information that plain text can obscure.
Keep log evidence attached to the match
For logs, ip-address-extractor and date-extractor provide candidate fields, but the match is only reviewable when its original line, nearby event text, and timezone assumption stay attached. Compare the extracted count and representative values with the fixture. A matching IP is still just an extracted value, not an identity conclusion, and a date string is not automatically a business event.
Treat sensitive fields as a separate review gate
If the input may contain contact or network identifiers, decide authorization and minimum scope before using bulk-email-extractor, phone-number-extractor, or ip-address-extractor. Restrict raw outputs, record the fields and rows released, and mask or pseudonymize the handoff when required. Accept the result only when the expected fields are present, unwanted matches are explained, source context is preserved, and the delivered artifact follows the handling policy. The extraction tools do not replace a redaction or access-control process.