# Index File Contents for Search
**URL:** https://meta.discourse.org/t/index-file-contents-for-search/31884
**Category:** Feature
**Tags:** ai, ai-search
**Created:** [August 7, 2015, 6:37pm UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884 "2015-08-07T18:37:32Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@ahuling](https://meta.discourse.org/u/ahuling)
#### Post date: [August 7, 2015, 6:37pm UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/1 "2015-08-07T18:37:32Z")
Right now, file names are indexed for search but the contents are not. It would be nice if the contents of files were also indexed, at least for the most common text-based files types, e.g. txt, pdf, doc, xls, csv, etc.
Any plans for this?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [August 7, 2015, 6:47pm UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/2 "2015-08-07T18:47:29Z")
No plans for this at the moment.
---
### Author:  [@DDo](https://meta.discourse.org/u/DDo)
#### Post date: [June 11, 2020, 7:06am UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/3 "2020-06-11T07:06:56Z")
“Me, too”
We’d like to have attachments (in our case, PDF’s) indexed for the search engine, too.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [June 11, 2020, 7:40am UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/4 "2020-06-11T07:40:46Z")
This is very much an enterprise customer type feature. We don’t have concrete plans here with a timeline, I am uncertain what would happen to Postgres with huge PDF documents.
Certainly something we have thought about over the years and may get to over the next few years.
---
### Author:  [@Craig\_Robben](https://meta.discourse.org/u/Craig_Robben)
#### Post date: [March 17, 2022, 8:58pm UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/5 "2022-03-17T20:58:02Z")
Curious if Discourse added the capability to index and search PDF’s yet?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [March 17, 2022, 11:16pm UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/6 "2022-03-17T23:16:56Z")
Not yet, very feasible to build though in a plugin.
---
### Author:  [@avandorp](https://meta.discourse.org/u/avandorp)
#### Post date: [June 29, 2022, 7:51am UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/7 "2022-06-29T07:51:49Z")
When developing such a plugin: Where would you start? Being totally new to the discourse code I’d probably try to hook in UploadCreator, but that might be very wrong.
---
### Author:  [@mjbergman92](https://meta.discourse.org/u/mjbergman92)
#### Post date: [October 16, 2024, 5:45pm UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/8 "2024-10-16T17:45:30Z")
Developing a Discourse plugin that integrated with [Paperless](https://github.com/paperless-ngx/paperless-ngx) would be a good start.
Such a plugin would be _involved_ to say the least, as stated before.
A plugin like this would require that the Discourse API allows for external handling of documents. Is that currently available?
This plugin would require integration with the search capabilities offered by the Discourse API. While this is not trivial, this has been done by several existing plugins, namely the discourse/discourse-algolia plugin.
Other Areas to Consider
- Backups
This would be something I would personally be interested in cutting my teeth on. I have started by looking at the [Paperless API](https://docs.paperless-ngx.com/api/) along with reverse engineering the discourse/discourse-algolia project… but there are others that integrate with search.
Any thoughts as to the choice of Paperless? I like how active the project is and the amount of issues they have closed in addition to the number of issues they have (currently 0).
---
### Author:  [@dennisjbr](https://meta.discourse.org/u/dennisjbr)
#### Post date: [September 23, 2025, 5:45am UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/10 "2025-09-23T05:45:07Z")
This would be a HUGE improvements especially for those forums that carry a lot of documentation via PDFs, scans, or images. If the scope of this limited to searching, then ideally you would just need to extract/create text and then store that text in a column in postgres. When you do that, then you can leverage the postgres full-text already in-place.
In linux for example, you could pdftotext to extract then text from a PDF and store in DB. Another (more expensive) idea is to use AI vision to explain/extract the pdf or image for storing in the DB.
Thoughts?
---
### Author:  [@dennisjbr](https://meta.discourse.org/u/dennisjbr)
#### Post date: [April 21, 2026, 7:34am UTC](https://meta.discourse.org/t/index-file-contents-for-search/31884/11 "2026-04-21T07:34:57Z")
So, I’ve been looking into this, and putting a wireframe together (with AI) on how to best achie this. There are a couple of ideas that come to mind. Using Apache TIKA would allow us to OCR almost any file type with text, including images. It would be a self-hosted option. And/Or: Use Gemini Flash 1.5 (for example) to not only perform OCR, but also describe images being seen and analyzed, then post that data in a PostgreSQL table/column for search. Of course, this requires a sizable investment of tokens upfront to rebake all posts with attachments/uploads, but it would be most useful. I suppose you get what you pay for?