On October 29, Google announced file previews and editing directly inside Gemini conversations. Users can make manual changes or request targeted revisions by highlighting text. PDF is supported on the web and mobile; the other announced formats are web-only. The company says availability extends wherever the app is offered.
From an answer to an inspectable file
The Workspace team’s announcement specifies opening a presentation in Slides or downloading PPTX/PDF, and transferring a spreadsheet into Sheets. These are provider descriptions, not our compatibility tests. The development is the preview-and-refinement workflow, rather than a claim that Gemini has only now gained any ability to generate files.
The help page additionally lists .docx, .xlsx, .csv, LaTeX, TXT, RTF and Markdown among generated formats. The same documentation says file uploads and integrations with other services require sign-in. Broad availability to users therefore does not imply identical signed-out capabilities in every context.
Why preview changes the workflow
Our editorial interpretation is that the useful change concerns where a correction happens. A user can identify a particular paragraph or visual problem instead of describing the entire document again. That may clarify intent, but does not establish that revised content is correct.
Imagine a project note with three tasks, owners and deadlines. The useful check is not simply whether it looks good inside the conversation. A reviewer needs to establish whether each deadline remains attached to the right task, names have stayed in place and the downloaded file matches the approved version. This is our proposed evaluation example, not a trial we performed.
For a spreadsheet, we would separate the appearance of numbers from their meaning. Correctly aligned columns do not prove correct formulas or units. For a presentation, we would check whether a significant qualification disappears when text is shortened. Those checks connect visual convenience with responsibility for the content.
What to evaluate before team adoption
We would start with a non-confidential sample document and a predefined expected result. After one manual change and one model-requested revision, we would compare the preview with the downloaded file in its intended application. Bulgarian text, wrapping, tables and page order would be particularly useful checks.
The team also needs to decide who approves the content and who retains the final version. If successive revisions have no clear completion point, easier editing may simply generate more versions. That organisational question is not solved automatically by an interface.
For work spanning a phone and desktop, the announced format distinction matters in planning the trial. A team should test the actual device and export route it expects to use, rather than infer that a successful PDF preview establishes the behaviour of every supported file type.
Google’s short announcement does not provide independent measurements of time saved or accuracy. We therefore attribute no such outcome. The verified development is a closer connection between conversation, file and editing, with a specific distinction between mobile and web support. Its benefit for a particular team needs to be established using that team’s real documents.
*Cover: AI illustration; a conceptual workspace, not a screenshot of Gemini.*
*Editorial verification: 30.10.2026, 19:35:25 +0200 (Europe/Sofia).*
